Bug reported by Martin Valkanov <m.valkanov.at.is-bg.net> Quote: "we recently migrated from fop 0.20.5 to 1.0dev (rev232979) and can not get text-align="justify" to work with custom fonts embedded in a pdf. It works ok with fop 0.20.5. Using the built-in font-family="Helvetica" or font-family="Courier" text is justified correctly."
Confirmed. It looks like nothing at all happens for embedded TrueType fonts and a not quite successful attempt for Type 1 fonts. Will have to investigate further. Does anybody know about some free, non-bullshit fonts (one TrueType and one Type 1, with kerning tables) that we could place in our repo for testing purposes? The license is important.
I have tried several times to get a collection of fonts into the FOray repository, but have been unable to get it done. There seem to be a lot of free fonts out there, but the ones I have found still have licensing restrictions that would prevent distribution of them. Another problem is that there are quite a few axes WRT fonts, and you could end up needing a fairly large number of fonts to cover the various issues, especially if you want to create tests that will handle poorly-constructed fonts properly. One less-than-ideal alternative might be to identify and document some commonly- used typefaces for which almost everyone will have a license, or perhaps to document the URL for downloading free fonts, so that everyone can at least go get the same thing from that location. Another alternative is to appeal to the user base to see if someone would take on the project of creating a set of fonts that could be used for testing. Since beauty of output is not the main object, hand-drawn stuff would be fine.
Look no further than your sister project (for TrueType): http://svn.apache.org/viewcvs.cgi/xmlgraphics/batik/trunk/samples/tests/resources/ttf/ You might use font-forge to convert that to Type 1. There is also a very simple SVG font that I did a while ago (useful for testing SVG text layout, among other things). It also has some kerning (although perhaps not a full set): http://svn.apache.org/viewcvs.cgi/xmlgraphics/batik/trunk/samples/strokeFont.svg I don't know if font-forge can do anything with SVG fonts.
Jeremias, it just tried to reproduce this and couldn't. In my example the custom font aligns just fine. Could it be that it is fixed as a side effect of other changes made by Luca to the Knuth elements for justification? Can you still reproduce it? BTW - very comprehensive lists of Unicode fonts (free, shareware, commercial) for (nearly) every possible script can be found at http://www.travelphrases.info/fonts.html and http://www.alanwood.net/unicode/.
(In reply to comment #4) > Jeremias, it just tried to reproduce this and couldn't. In my example the > custom font aligns just fine. Could it be that it is fixed as a side effect of > other changes made by Luca to the Knuth elements for justification? Can you > still reproduce it? Yes, I can. I configured the Windows Arial font in the font config and used that font with text-align="justify".
To document what's wrong, here are two PDF lines generated once with FOP 0.20.5 and once with FOP Trunk. This illustrates what is done differently: Fop 0.20.5: 1 0 0 1 56.692 678.637 Tm [<00040005000600070008> -293.0 <0009000a000b000c0008> -293.0 <000d0005000e00050006> -293.0 <000b0009000f> -293.0 <001000080007000f0011> -293.0 <001200050013000b00070012000f0007000f000c00070006> -293.0 <0010000d0009000a0009000b0012000900130014> -293.0 <0007000e0009000f0015> -293.0 <00160013> -293.0 <0017000c0009000b> -293.0 <000f00050006000f000500060015> -293.0 <001800190010000b0007000e000e000c000b> -293.0 <0010000f> -293.0 <0005000600120009> -293.0 <00100012> ] TJ FOP Trunk: 1 0 0 -1 0.0 112.164 Tm 0.0 Tc 1.437 Tw [<000500060007000800090003000A000B000C000D00090003000E0006000F000600070003000C000A00100003001100090008001000120003001300060014000C00080013001000080010000D0008000700030011000E000A000B000A000C0013000A0014001500030008000F000A0010001600030017001400030018000D000A000C0003001000060007001000060007001600030019001A0011000C0008000F000F000D000C0003001100100003000600070013000A> ] TJ Looks like the spaces don't get recognized by the PDF implementation this way.
I'm not sure this is directly related to the bug: it seems that 0.20.5 creates a text area for each word / space, while trunk creates a single text area for all the text a TextLM has to put in a line (this is done in TextLM.addAreas, and until a few months ago trunk created several text areas too). I did a simple test with two justified blocks with the same text, one using the default font, the other an embedded font, and this is the resulting output (I just added System.out.println(pdf.toString()) in PDFRenderer.renderText()): (block with the default font) /F1 12.0 Tf 0 g 1 0 0 -1 0.0 10.266 Tm 0.0 Tc 0.047 Tw [(Font test; some text in order to discover why there are justification) /F1 12.0 Tf 1 0 0 -1 0.0 24.666 Tm 0.0 Tc -1.081 Tw [(problems whit embedded fonts. More text to create more lines: what) /F1 12.0 Tf 1 0 0 -1 0.0 39.066 Tm 0.0 Tc 0.0 Tw [(happens?) (block with the embedded font) /F15 12.0 Tf 0 g 1 0 0 -1 0.0 54.564 Tm 0.0 Tc 0.072 Tw [<0005000600070008000300080009000A0008000B0003000A0006000C0009000300080009000D00080003000E000700030006000F00100009000F00030008000600030010000E000A0011000600120009000F00030013001400150003000800140009000F000900030016000F0009000300170018000A0008000E0019000E001100160008000E00060007> /F15 12.0 Tf 1 0 0 -1 0.0 68.964 Tm 0.0 Tc -1.057 Tw [<001A000F0006001B001C0009000C000A000300130014000E000800030009000C001B0009001000100009001000030019000600070008000A001D0003001E0006000F0009000300080009000D000800030008000600030011000F00090016000800090003000C0006000F00090003001C000E00070009000A001F00030013001400160008> /F15 12.0 Tf 1 0 0 -1 0.0 83.364 Tm 0.0 Tc 0.0 Tw [<00140016001A001A00090007000A0020> The only difference (apart from small differences in the numeric values) is that the embedded font is multibyte. Maybe the different encoding of a space character prevents the adjustment to be applied? Regards Luca
Quotation from the pdf reference, version 1.6, section 5.2.2 Word spacing: "Word spacing is applied to every occurrence of the single-byte character code 32 in a string when using a simple font or a composite font that defines code 32 as a single-byte code. It does not apply to occurrences of the byte value 32 in multiple-byte codes." So, it seems that at least we have found where the problem lies ... anyone has an idea how to solve it too? :-) Regards Luca
resetting P2 open bugs to P3 pending further review
change status from ASSIGNED to NEW for consistency