Why doesn't Graphic LCD (128x64) automatically changes line
The indicated display is electrically wired as two 64x64 displays which are placed side by side, and should be thought of in such terms.  The data sheet does not provide any way of reading out the current value of X and Y registers, but your code should be able to keep track of what it has written to the display.  The display does provide a function to read out data at the current address, but I would recommend that for best performance you avoid using it.  Instead, draw to an off-screen buffer and copy data to the LCD when you are done.  In many cases, such an approach can be more than twice as fast as approaches that have to read and write an LCD.

If you are using something like a PIC, and your display will consist of some number of horizontal slices of proportional text, such that no characters will cross a slice boundary, and no slice is more than e.g. 10 pixels tall, I would suggest that you have two 20-byte buffers of ten 16-bit integers and an X counter.  Process characters within the slice in order by the X coordinate of the leftmost edge.  Start with both buffers clear and the counter equal to 0.

To process a character, start by doing something like:

while(counter_X &lt; char_left)
{
  counter_X++;
  buffer[0] &lt;&lt;= 1; buffer[1] &lt;&lt;= 1;
  buffer[2] &lt;&lt;= 1; buffer[3] &lt;&lt;= 1;
  buffer[4] &lt;&lt;= 1; buffer[5] &lt;&lt;= 1;
  buffer[6] &lt;&lt;= 1; buffer[7] &lt;&lt;= 1;
  buffer[8] &lt;&lt;= 1; buffer[9] &lt;&lt;= 1;
  if ((counter_X &amp; 7) == 0)
    show_buffer(((counter_x) &gt;&gt; 3)-1, slice_y, slice_height); // Show *upper* bytes
}


On the PIC and many other processors, hard-coding the shifts will be much faster than using a loop [even if the slice might sometimes be less than 10 rows high].  The show_buffer routine should set the display to start writing bytes at the indicated X and Y address, and then write the all the bytes of the slice.

Once counter_X equals the coordinate of the right edge of the character, draw the character into the the lower bytes of the buffer using the Boolean "or" operator (|=).  Character data written at X position 0 will be shifted left 8 times before the MSB of each byte gets sent to the display; data at position 1 will be shifted left 7 times before it's written to the display, but the last bit will remain behind for the next display operation.

Once all character data is written, run the above shifting loop with char_left equal to 128 to force the system to write all remaining data for the stripe.

This approach makes it possible to produce professional-looking proportionally-spaced text very quickly, since there are no unnecessary display-write operations.  The only not-100%-necessary operations versus an optimal display update would be the "set X coordinate" and "set Y coordinate" commands which would be sent roughly every every 10 bytes, many of which could be eliminated if the "slice buffer" were a full 64 bytes tall.  Even if slices were only 6 lines tall (one was showing tiny text), the overhead would be at most 50%.  By contrast, trying to use read-modify-write to draw the text without the on-screen buffer would likely require two or three reads or writes for each byte of display memory--at least 4 to 6 times slower.