Re: DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors
Simon Pepping wrote: I believe the reason why justification still doesnt work after correcting the issues you've found is because TextLM.addAreas doesnt create separate areas for each word - it creates one big area in some cases for whole line, so there is no opportunity to add space adjust for justification. The layout managers only do the calculations. The renderers need to do the real work, i.e. apply the calculation to the line to be rendered. The LM can help by splitting up the line in a number of text areas, or the renderer can scan the unsplit text areas and apply stretching to the white space in it. There was a discussion about this topic on this list some time ago. Yes, I was the one who started the previous discussion. Joerg was pushing for the Renderers to do the splitting too. But I disagree with this approach because the LMs have already worked out the BPs, why make the Renderers do it again. This is very inefficient approach dont you think? I believe changing the TextLM.addAreas to generate an area for each BP if justification is on is the most efficient way of implementing justification. Chris
[Fwd: DO NOT REPLY [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly]
Comments most welcome. Glen, In general I like your solution. However, I did a bit of testing with inlines and the effects are very serious. Valid non-whitespace characters from the enclosing block are simply deleted if there is whitespace at the start of the fo:inline. Chris
Re: DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors
Chris Bowditch wrote: Simon Pepping wrote: I believe the reason why justification still doesnt work after correcting the issues you've found is because TextLM.addAreas doesnt create separate areas for each word - it creates one big area in some cases for whole line, so there is no opportunity to add space adjust for justification. The layout managers only do the calculations. The renderers need to do the real work, i.e. apply the calculation to the line to be rendered. The LM can help by splitting up the line in a number of text areas, or the renderer can scan the unsplit text areas and apply stretching to the white space in it. There was a discussion about this topic on this list some time ago. Yes, I was the one who started the previous discussion. Joerg was pushing for the Renderers to do the splitting too. But I disagree with this approach because the LMs have already worked out the BPs, why make the Renderers do it again. This is very inefficient approach dont you think? I believe changing the TextLM.addAreas to generate an area for each BP if justification is on is the most efficient way of implementing justification. Just want to add that I realise changing TextLM.addAreas isnt the only other change required to get jusitification working. The Renderers will need changing too, but I'm against the renderers computing their own splits, just give them each word as its own area if justification is on. Chris
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27773.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27773
[PATCH] Hyphenation
--- Additional Comments From [EMAIL PROTECTED] 2004-04-05 09:22 ---
Hi all
I apologize for having posted some proposed changes without a line explaining
what I was changing and why.
Really sorry, I'm going to try and do it now.
First of all, the condition now tested in the
LineLayoutManager.getNextBreakPoss() to decide whether or not to try
hyphenation is:
if (bTextAlignment == TextAlign.JUSTIFY || prevBP == null) {
...
}
So hyphenation is tried for *every* justified block of text; only if
the language attribute is not set the getHyphenContext() method returns null
and hyphenation is not actually done.
My suggestion is to change it so that the fo property hyphenate (7.9.4 in the
recommendation, and already implemented in the CommonHyphenation class) is
tested instead:
if (hyphProps.hyphenate == Constants.TRUE) {
...
}
In the TextInfo class there is a boolean attribute called bCanHyphenate, but
it is given a default value of true, and it is no more modified. It seems to
me that it is quite useless.
Is is used in the TextLayoutManager.getHyphenIPD() method:
if (textArray.length iStopIndex || foText.textInfo.bCanHyphenate == false)
{
...
}
but this method is called only if context.tryHyphenate() is true; with my
suggested change, context.tryHyphenate() returns true only if the fo property
hyphenate is true, and so it is no more necessary to test
foText.textInfo.bCanHyphenate.
The second problem is that the hyphenation character is not shown: to fix this
I added in the AreaInfo class (which stores information about the area that
will be generated) a boolean attribute bHyphenated.
Is is set according to the value of the flags of the corresponding BreakPoss,
and it is tested in the TextLayoutManager.addAreas() method to decide whether
to add the hyphen.
Last (and least): I tried to implement the fo property hyphenation-character
(7.9.5 in the recommendation).
As it applies to blocks, I thought to store it as a character variable in the
TextInfo class, with initial value -.
It is set in the PropertyManager.getTextLayoutProps() method, together with
the other TextInfo attribute.
Is is used to calculate the hyphIPD in the TextLayoutManager constructor, and
in the addAreas method.
Bye
Luca
DO NOT REPLY [Bug 28130] - [PATCH] Errors in the calculation of adjustment factors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28130. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28130 [PATCH] Errors in the calculation of adjustment factors --- Additional Comments From [EMAIL PROTECTED] 2004-04-05 13:54 --- Hi again I have tried to make PDFRenderer use the adjustment factor without splitting the text in different areas, and it seems it now works (except when hyphenation is done, but that's another bug). Only a quick note: as the pdf operator controlling space adjust (Tw) can take a float, space adjustment could be stored as double instead of casting it into an int. I am going to attach the suggested patch. Bye Luca
DO NOT REPLY [Bug 28130] - [PATCH] Errors in the calculation of adjustment factors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28130. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28130 [PATCH] Errors in the calculation of adjustment factors --- Additional Comments From [EMAIL PROTECTED] 2004-04-05 13:56 --- Created an attachment (id=11134) patch to pdf renderer, so that it uses the adjustment factor
DO NOT REPLY [Bug 28208] New: - [PATCH] justification in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28208. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28208 [PATCH] justification in PDF Renderer Summary: [PATCH] justification in PDF Renderer Product: Fop Version: 1.0dev Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Copied Luca's Furini's PDF Renderer patch for justification from resolved bug 28130
DO NOT REPLY [Bug 28208] - [PATCH] justification in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28208. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28208 [PATCH] justification in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2004-04-05 14:06 --- Created an attachment (id=11135) suggested patch
DO NOT REPLY [Bug 28130] - [PATCH] Errors in the calculation of adjustment factors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28130. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28130 [PATCH] Errors in the calculation of adjustment factors --- Additional Comments From [EMAIL PROTECTED] 2004-04-05 14:07 --- Hi Luca, thanks for your new suggested patch. Since this bug is closed I have created a new bug for your new patch. http://issues.apache.org/bugzilla/show_bug.cgi?id=28208
DO NOT REPLY [Bug 28208] - [PATCH] justification in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28208. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28208 [PATCH] justification in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2004-04-05 14:08 --- Created an attachment (id=11136) test fo file
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27773 [PATCH] Hyphenation --- Additional Comments From [EMAIL PROTECTED] 2004-04-05 16:40 --- Sorry, I'm here again (hope I am not making too much a mess!) :-) I'm going to attach an updated proposed patch, as I noticed there was an error in the one I posted before. In the TextLayoutManager.addAreas() method, the hyphen size must be added to the total inline progression dimension of the line *before* the adjustment calculation; this involves also moving a few lines of code. Bye Luca
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27773 [PATCH] Hyphenation --- Additional Comments From [EMAIL PROTECTED] 2004-04-05 16:41 --- Created an attachment (id=11138) updated diff
Re: [Fwd: DO NOT REPLY [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly]
Yes, this needs more work then. I did not consider fo:inlines when starting. Still, I'm surprised that fo:inlines are within the same FOText object (the fo:block is already parsed into several FOText objects, roughly FOText object per line in the source document)--the appearance of an fo:inline should precipitate a new FOText object, one would think. That could be one solution. Glen --- Chris Bowditch [EMAIL PROTECTED] wrote: Comments most welcome. Glen, In general I like your solution. However, I did a bit of testing with inlines and the effects are very serious. Valid non-whitespace characters from the enclosing block are simply deleted if there is whitespace at the start of the fo:inline. Chris
