xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 49411] using language attribute breaks linefeed-treatment="preserve" rendered block
Date Wed, 16 Jun 2010 18:20:12 GMT

Andreas L. Delmelle <adelmelle@apache.org> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
          Component|fo tree                     |page-master/layout
           Platform|PC                          |All
            Version|0.95                        |1.0dev
         Resolution|                            |DUPLICATE
         OS/Version|Windows XP                  |All

--- Comment #1 from Andreas L. Delmelle <adelmelle@apache.org> 2010-06-16 14:20:08 EDT
(In reply to comment #0)
> Without the language="en"  attribute the output is (as expected)
> First line
> Second line
> This seems to be independent of the chosen output format.

Apologies for the late reply...

The real issue seems to be the combination of hyphenation with preserved
linefeeds, which is a registered, as yet unsolved bug. See Bug #38264. 
I last had a look at that one over two years ago, but I think the basic story
as sketched in that report still holds: three paragraphs are generated by the
line-breaking algorithm (two genuine and an empty one), which are
post-processed to apply hyphenation, and this post-processing implicitly
assumes that a TextLM will always generate one and only one paragraph.

When you remove the language attribute, hyphenation is not triggered, so the
issue does not occur. If you really get hyphenation points and have more
preserved linefeeds, the effects are reinforced. In extreme cases, you hardly
recognize the original text.

So, I got that itch again, and dove into the code... 
I already solved this particular manifestation in my local sandbox, simply by
doing something I initially expected would already help: invert the principal
loop in LineLM.createLineBreaks(). 
Unless I am missing something, there really seems to be no benefit in that loop
going backward, unless of course one considers confusing people trying to
follow the flow to be beneficial... Errm... :->
This solves the issue, but only in this very confined testcase. The hyphenation
'updates' are still applied twice, but there really is no difference (= none of
the calculated hyphenation points are actually used, since both pieces of text
fit well within one line)

I am marking this one as duplicate. Please post any follow-up at #38264

*** This bug has been marked as a duplicate of bug 38264 ***

Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

View raw message