Re: IPDAdjust
> / >> Unfortunately, the original reporter did not take the time to reduce >> the example to a 'minimal' one. >> ... >> which makes it more difficult to pinpoint the cause. >> > > I am willing to reduce it a bit, but all next week I won't have an access to > my PC. No worries, I already got that covered. :) Same basic structure, only two fo:inlines instead of one, where the first has a keep-with-next specified and the second a keep-together. The intention seems to be to allow for multi-line entries, see 1.1.13, 1.1.14 and 1.1.17 in the sample attached to FOP-1444. I think the same issue responsible for the glitch is also triggering the line break in entry 1.1.13 too soon. Not entirely certain, but it seems like the word 'here' followed by two spaces, a leader and a digit would actually still fit in the line (?) BTW, I also spoke too soon about FOP-1162, which still has one single entry in the TOC that exhibits the same glitch with a very similar content length range. Same structure, so seems to be the same issue. Replacing the fo:page-number-citations with literal numbers demonstrates that it is definitely related to the use of those. That introduces an additional stretchable piece of content, where the real optimum width is not known at the point where the line breaks have to be determined. If the TOC were placed at the end of the document in its own page-sequence, the problem would go away, as all the effective page numbers are known at that point. > I remember there is another justification issue, even with a patch: > https://issues.apache.org/jira/browse/FOP-2438 > > But I suppose there is no nbsp character in the original test case so it has > to be something else. Hmm... Seems like that is indeed indirectly related, and could be the basis for an alternative solution. Looking at the patch, it does seem rather drastic to remove the condition altogether and always use stretchable glues. In plain start/end aligned context, it is overhead to generate a sequence of three elements instead of one. I'll look into whether extending that condition to cover the text-align-last case is feasible. > Just a note, comparing both FOP-1444-original.pdf and > FOP-1444-original_after.pdf in separate browser tabs (and 'animating' the > difference by activating them) I can see changes in the right edge position > of all the page numbers except 'glitches'. Like they would be untouched by > your code... Correct. I noticed that as well... I did expect that, since before my change, the glyph mapping used for the space area had a larger max ipd than the element as seen by the line-breaking algorithm. I just assumed that previously those lines were actually overflowing, all by the same amount. To say for certain, I would have to check in more detail if the result for all but the glitched lines is 100% correct, i.e. the area ipd values should add up exactly to the available ipd for the line area. KR Andreas
RE: IPDAdjust
On 2015-07-24 Andreas L. Delmelle wrote: > > https://issues.apache.org/jira/secure/attachment/12558413/FOP_TOC_Bug_T > est.fo > > I tried that one indeed, and noticed it still has misalignments, albeit > very minor. Just a note, comparing both FOP-1444-original.pdf and FOP-1444-original_after.pdf in separate browser tabs (and 'animating' the difference by activating them) I can see changes in the right edge position of all the page numbers except 'glitches'. Like they would be untouched by your code... Jan
RE: IPDAdjust
On 2015-07-24 Andreas L. Delmelle wrote: > I tried that one indeed, and noticed it still has misalignments, albeit > very minor. Overall, the alignment does look a bit better than before > the patch and quite a lot better than the originally attached PDF from > 8 years ago, but still not entirely OK. I just attached both outputs in > JIRA, so you can have a look if you're interested. We are almost there :-) > Unfortunately, the original reporter did not take the time to reduce > the example to a 'minimal' one. > ... > which makes it more difficult to pinpoint the cause. > I am willing to reduce it a bit, but all next week I won't have an access to my PC. > One notable difference with your attachment is that instead of > absolute, resolved page numbers, that example uses fo:page-number- > citation, so it could be related to those. Another possibility is that > the list structure is causing interference. Difficult to say at this > point. I remember there is another justification issue, even with a patch: https://issues.apache.org/jira/browse/FOP-2438 But I suppose there is no nbsp character in the original test case so it has to be something else. Jan
[jira] [Commented] (FOP-1777) Support for Font Kerning is Broken
[ https://issues.apache.org/jira/browse/FOP-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640553#comment-14640553 ] Thanasis Giannimaras commented on FOP-1777: --- Fix for handling kerning for unencoded characters. Patch based on work provided by Luis Bernado with few changes. For mitigating potential performance issues, kerning has been disabled by deault (default option was true). As i could not include Nimbus Sans L font in fop, due to its license, for junit testing i used Bitstream Charter Regular (http://www.math.utah.edu/~beebe/fonts/charter-1.0.zip) which come with a more open, less restrictive license. > Support for Font Kerning is Broken > -- > > Key: FOP-1777 > URL: https://issues.apache.org/jira/browse/FOP-1777 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Vincent Hennebert > Attachments: bchr.README, bchr.afm, bchr.pfb, fop.xconf, kerning.fo, > kerning.pdf, kerningTrunk.patch, kerningTrunk.pdf, > screenshot-openoffice-writer.png > > > The method o.a.f.fonts.Font.getKernValue expects two Unicode code points and > returns the amount of kerning between the two corresponding glyphs. However, > the implementation for Type 1 fonts interprets the two integers as character > codes in the font's internal encoding (see o.a.f.fonts.type1.AFMFile.java). > Those usually have nothing to do with Unicode code points. > Moreover, trying to get kerning between two characters is inherently wrong: > kerning applies to glyphs and not characters. A font may have several glyph > variants for a same character, and kerning is likely to be different for each > variant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-1777) Support for Font Kerning is Broken
[ https://issues.apache.org/jira/browse/FOP-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thanasis Giannimaras updated FOP-1777: -- Attachment: kerningTrunk.pdf kerningTrunk.patch fop.xconf bchr.README bchr.pfb bchr.afm > Support for Font Kerning is Broken > -- > > Key: FOP-1777 > URL: https://issues.apache.org/jira/browse/FOP-1777 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Vincent Hennebert > Attachments: bchr.README, bchr.afm, bchr.pfb, fop.xconf, kerning.fo, > kerning.pdf, kerningTrunk.patch, kerningTrunk.pdf, > screenshot-openoffice-writer.png > > > The method o.a.f.fonts.Font.getKernValue expects two Unicode code points and > returns the amount of kerning between the two corresponding glyphs. However, > the implementation for Type 1 fonts interprets the two integers as character > codes in the font's internal encoding (see o.a.f.fonts.type1.AFMFile.java). > Those usually have nothing to do with Unicode code points. > Moreover, trying to get kerning between two characters is inherently wrong: > kerning applies to glyphs and not characters. A font may have several glyph > variants for a same character, and kerning is likely to be different for each > variant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: IPDAdjust
> On 24 Jul 2015, at 15:00, Andreas L. Delmelle > wrote: > >> On 24 Jul 2015, at 12:08, Jan Tosovsky wrote: >> >> Are you referring to Pascal comment from 16/Oct/13? In this case I'd rather >> create a dedicated issue (if it is still relevant) as the original text and >> majority of comments is IMHO about incorrect alignment when a leader is >> surrounded with spaces. They can be either eliminated (as a workaround) or >> handled properly, which I believe is covered by your changes. > > Good point. Interesting addition, in support of that: I just noticed that my proposed change does seem to resolve the related issue (FOP-1162) entirely. Without that change to TextLM, the output still appears slightly misaligned. After the change, the whole TOC in that document looks neatly justified as well. Yea! :) KR Andreas
Re: IPDAdjust
> On 24 Jul 2015, at 12:08, Jan Tosovsky wrote: > > On 2015-07-24 Andreas L. Delmelle wrote: >> On the other hand, note that it does not (entirely) solve the original >> issue reported in FOP-1444, which seems to be more related to using >> fo:page-number-citation. > > Are you referring to Pascal comment from 16/Oct/13? In this case I'd rather > create a dedicated issue (if it is still relevant) as the original text and > majority of comments is IMHO about incorrect alignment when a leader is > surrounded with spaces. They can be either eliminated (as a workaround) or > handled properly, which I believe is covered by your changes. Good point. > > Are you getting the proper alignment when processing the original attachment? > https://issues.apache.org/jira/secure/attachment/12558413/FOP_TOC_Bug_Test.fo I tried that one indeed, and noticed it still has misalignments, albeit very minor. Overall, the alignment does look a bit better than before the patch and quite a lot better than the originally attached PDF from 8 years ago, but still not entirely OK. I just attached both outputs in JIRA, so you can have a look if you're interested. Unfortunately, the original reporter did not take the time to reduce the example to a 'minimal' one. It contains more page-sequence-masters than the rendered output has pages, which leaves us with the task of having to reduce it to the smallest example that reproduces the issue at hand. Debugging a session with the attachment as is produces too much noise, which makes it more difficult to pinpoint the cause. One notable difference with your attachment is that instead of absolute, resolved page numbers, that example uses fo:page-number-citation, so it could be related to those. Another possibility is that the list structure is causing interference. Difficult to say at this point. KR Andreas
[jira] [Updated] (FOP-1444) PDF table of contents generated with incorrect page number alignments
[ https://issues.apache.org/jira/browse/FOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-1444: - Attachment: FOP-1444-original.pdf FOP-1444-original_after.pdf * FOP-1444-original.pdf is the result of rendering the original FO attachment with current FOP trunk (basically 2.0), which already looks quite a lot better than the originally attached PDF. * FOP-1444-original_after.pdf is the result of rendering the same FO after a very minor update in TextLM, looking slightly better even, but still not entirely without issues. The lines with 'glitch' in them still appear a bit 'off' with respect to the others. Cause of that still remains to be determined > PDF table of contents generated with incorrect page number alignments > - > > Key: FOP-1444 > URL: https://issues.apache.org/jira/browse/FOP-1444 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 0.94, trunk > Environment: Operating System: Windows XP > Platform: PC >Reporter: David H. Gutteridge > Attachments: FOP-1444-original.pdf, FOP-1444-original_after.pdf, > FOP_TOC_Bug_Test-dbk1.78-nospc.pdf, FOP_TOC_Bug_Test-dbk1.78.0-nospc.fo, > FOP_TOC_Bug_Test-dbk1.78.0.fo, FOP_TOC_Bug_Test-dbk1.78.pdf, > FOP_TOC_Bug_Test.dbk, FOP_TOC_Bug_Test.fo, FOP_TOC_Bug_Test.pdf, toc.fo, > toc.pdf > > > It seems there's a threshold where FOP does not align page number references > correctly when generating tables of contents in PDF documents. I see that you > have a reference to this in your FAQ (question 3.10), but it says "The most > recent FOP releases should have this problem fixed", I'm seeing this problem > with 0.94. > (I have a sample FO document I will attach, looks like the initial bug > reporting > interface doesn't let me do this.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
RE: IPDAdjust
Hi Andreas, On 2015-07-24 Andreas L. Delmelle wrote: > > On 2015-07-23 Jan Tosovsky wrote: > > > > Do you expect this difference should be further eliminated or your > > patch is ready for incorporating into trunk? > > ... > On the other hand, note that it does not (entirely) solve the original > issue reported in FOP-1444, which seems to be more related to using > fo:page-number-citation. Are you referring to Pascal comment from 16/Oct/13? In this case I'd rather create a dedicated issue (if it is still relevant) as the original text and majority of comments is IMHO about incorrect alignment when a leader is surrounded with spaces. They can be either eliminated (as a workaround) or handled properly, which I believe is covered by your changes. Are you getting the proper alignment when processing the original attachment? https://issues.apache.org/jira/secure/attachment/12558413/FOP_TOC_Bug_Test.fo > > > > From my (naive) point of view, wouldn't be possible - during > > processing whitespace - somehow process that fixed width box (if > > breakOpportunity is false) in same way like in the second case (glue)? > > Possibly, but not sure if it would be worth the time and effort to > investigate that right now. Ok. > I keep staring at both lines, and wonder whether either one looks > 'better' than the other, but I cannot decide... :) I also believe no one will notice a difference. The most frequent use cases are TOCs, where the FO structure is same so there is no need to vaste time with further tweaking. Thanks a lot for your valuable work! Jan
Re: IPDAdjust
Hi Jan > On 23 Jul 2015, at 21:47, Jan Tosovsky wrote: > > > Do you expect this difference should be further eliminated or your patch is > ready for incorporating into trunk? At first glance, it looks like the change can be committed to trunk with little risk. That is: it does not break any existing tests, and would offer a solution for this new one. On the other hand, note that it does not (entirely) solve the original issue reported in FOP-1444, which seems to be more related to using fo:page-number-citation. > > From my (naive) point of view, wouldn't be possible - during processing > whitespace - somehow process that fixed width box (if breakOpportunity is > false) in same way like in the second case (glue)? Possibly, but not sure if it would be worth the time and effort to investigate that right now. Purely from the perspective of the layout algorithm, one can expect different input to lead to a difference in output. In the first case, there is only one stretchable piece of content in the line, namely the fo:leader. The space behaves like a NBSP here, which is never stretched. In the second, there are two, which leads to the total stretch/shrink for the line being distributed over those two, which is where that ~1400mpt (about 0.5mm) comes from. I keep staring at both lines, and wonder whether either one looks 'better' than the other, but I cannot decide... :) That said, before one even notices said difference, at least two conditions need to be satisfied: 1° the content of the two lines (blocks) is similar enough (read: almost identical) 2° one block should be using keep-together, while the other does not Even under those two conditions, the lines also need to be close enough together. If either one of the lines appeared at the top of a page, and the other in the middle or at the bottom, I doubt I would even have noticed it in the rendered PDF in the first place. KR Andreas
