Bug 36238

Summary: text-align="justify" doesn't work on custom fonts
Product: Fop - Now in Jira Reporter: Chris Bowditch <bowditch_chris>
Component: pdfAssignee: fop-dev
Status: NEW ---    
Severity: normal CC: taffy-tyler6464
Priority: P3    
Version: trunk   
Target Milestone: ---   
Hardware: All   
OS: All   
URL: http://marc.theaimsgroup.com/?t=112429497300002&r=1&w=2

Description Chris Bowditch 2005-08-18 10:09:50 UTC
Bug reported by Martin Valkanov <m.valkanov.at.is-bg.net>


"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
It works ok with fop 0.20.5.

Using the built-in font-family="Helvetica" or font-family="Courier" text is
justified correctly."
Comment 1 Jeremias Maerki 2005-08-19 09:39:51 UTC
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 

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.
Comment 2 Victor Mote 2005-08-19 17:01:40 UTC
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.
Comment 3 Thomas Deweese 2005-08-25 12:02:56 UTC
Look no further than your sister project (for TrueType):

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):


I don't know if font-forge can do anything with SVG fonts.
Comment 4 Manuel Mall 2005-10-10 02:06:22 UTC
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/.
Comment 5 Jeremias Maerki 2005-10-10 08:43:47 UTC
(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".
Comment 6 Jeremias Maerki 2005-10-10 10:09:53 UTC
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
] TJ

Looks like the spaces don't get recognized by the PDF implementation this way.
Comment 7 Luca Furini 2005-10-18 12:35:14 UTC
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

/F15 12.0 Tf
1 0 0 -1 0.0 68.964 Tm 0.0 Tc -1.057 Tw

/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?

Comment 8 Luca Furini 2005-10-18 12:53:22 UTC
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? :-)

Comment 9 Glenn Adams 2012-04-07 01:44:56 UTC
resetting P2 open bugs to P3 pending further review
Comment 10 Glenn Adams 2012-04-11 06:17:07 UTC
change status from ASSIGNED to NEW for consistency