GNOME Bugzilla – Bug 164230
Positioning of glyphs within glyph string
Last modified: 2005-03-24 20:47:42 UTC
Please describe the problem: Printing hebrew with vowels/accents via gnome-print/pango get screwed. This happens with Opentype fonts (SBL Hebrew/Ezra SIL) which render OK on screen with gtk/pango (and even in the gnome-print preview), but not using the postscript/PDF backend. Steps to reproduce: Actual results: Expected results: Does this happen every time? Yes Other information:
Created attachment 36085 [details] Wrongly printed hebrew text
Created attachment 36086 [details] test application, that produced the above postscript file
Comment on attachment 36086 [details] test application, that produced the above postscript file oops sorry, bugzilla didn't recognize text/plain automatically..
There's two separate issues here: 1. gnome-print-pango.c has a sign wrong for vertical positioning of glyphs. 2. gnome-print-pdf.c ignores positioning of glyphs within a glyph list entirely. I'll attach a patch soon here that fixes both.
Created attachment 38609 [details] [review] Patch fixing glyphlist positioning The patch I'm attaching fixes up GPOS adjustments in Pango output when printing to PDF for me. I'm afraid it's a little hard since there is a fair bit of reorganization. I had to combine the NEED_SUBSETTING() and !NEED_SUBSETTING() branches to maintain sanity in the code. The basic change in the patch is that instead of just drawing each string with a single Tj, we use TJ so that we can insert horizontal positioning. We track the difference between the position in the glyph list and where we think a PDF viewer will position the glyph so that we only need to reposition when necessary ... in the simplest case the expansion is small ... (\1\2\3) Tj becomes [(\1\2\3)] TJ To deal with vertical positioning, we break the TJ into two pieces and add a Ts operator to set the "rise". (Then set the rise back to zero after drawing the string) An alternate approach would have been to break the text into multiple "lines" and position each line with Td. The approach I took here is a bit more compact, and has the nice property that two characters that are *exactly* horizontally or vertically aligned are encoded that way in that file. Because Td repositions from scratch, I saw some round-off errors where a mark would get fractionally off from a glyph when I tried that approach. The approach here does count on being able to predict where the PDF viewer will put each glyph. Yould could imagine getting accumulated error over a long justified line so it didn't end up in exactly the right place ... however, in some experiments I did, I didn't see any problems. The patch also: - Fixes a bug in gnome-print-pango.c with the sign for a y offset - Adds G_GNUC_PRINTF() attribute to pdf_page_fprintf() ... I was struggling a lot with messed argument order - Removes some uses of %g (see bug 170106) - Removes the relevant FIXME
aarrrgggh I did not see this patch and implemented the same functionality for pdf and ps2. I'll add the gnome-pango patch, and added a number of G_GNUC_PRINTFs Owen : I did not support y motion in the my variant. Could you have a look at the code in CVS/2.10.2 ? A few issues I was not clear on 1) The delta was frequently non-0, is something doing kerning (see 158424) ? 2) I scaled by tm rather an font->scale. *** This bug has been marked as a duplicate of 158424 ***
Ugh, I guess I missed the other bug. The y positioning is necessary ... Thai, for example, will render completely wrong without it. And unfortunately, most of the complexity in my patch is from the y positioning.... I'm not sure that adding the Y positioning to what you have is going to be easier than backing it out for PDF and using my patch. :-( 1) Pango does do kerning by default. My patch also sometimes adds positioning for what looks like rounding differences, though usually just a few thousandths of a unit. 2) I'm pretty sure you want font->size not Tm[0]. In fact, for a 90 degree rotation, I think your code is going to give you a divide-by-zero. The TJ units are in 1000ths of a unit in unscaled font space - and the way we set up font space is that the font is 1 unit high, so font->size is the right factor from our font space to our user space where the font is font->size units high. Tm on the other hand is the matrix from font space to the *PDF* user space. But the PDF user space isn't the same as our user space.
I just tried the supplied test program for ps and pdf both look correct in CVS head.