As you can see, this doesn't really matter so much. With a fixed amount of RAM, the graphing code would have to generate a narrower band. But instead it would take fewer bands until the page is full. In this case, the printer is an Epson LX-300, so unless I'm not too wrong, you will have to make extensive rework on it to manage a landscape paper feed.

The example I did with a 48 pixel high buffer was just because 45/48 was a good quota, i.e. the number of vertical bytes quite closely matched n*9 pins. But it was quite a long time since I did play with a 9-pin matrix printer, so I kind of goofed on the calculation. I think the 9th pin is only for text output, and the graphics modes using 8 pins. That would make it even easier to find a suitable band size depending on horisontal resolution and paper width.

Being desperate, you might even rely on the printer having enough RAM for a full pass of the printer head, and split the line in two, with a pause in the middle of the transfer of each row to compute more data. Remember that the printer has its own processor - the OPs processor will not have to worry about the real-time requirements when a row of data is printed. But the program may have to wait with transmitting more data while the printer is busy printing a line. If I remember correctly, the old matrix printers did not flag ready during printing of a line - at least not in graphics mode where the printer may not even have had enough RAM for a second line of data.

Using narrower bands when printing doesn't change the complexity of the code, and need not affect the printing speed so much either. After all, a lot of the printing time will come from the mechanical limitations of the printer. It takes time for the printer to hit with its nails, and a lowly 12-cycle 8051 can compute quite a lot of pixels every second. And while two-way printing was fine for fast output of text, the graphics would only be sent out in one direction and then require the head to be returned before the next line of data. Printing graphical characters in dual-direction mode clearly shows breaks in vertical lines because of imperfect mechanical precision.