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-06 10:34 ---
There is still a problem concerning the way the PDFRenderer behave when the
text of a line comes from different TLM (I'm going to attach a test fo file
showing this problem).
[from PDFRenderer.renderText(), /*** comments added ***/]
...
if (!textOpen || bl != prevWordY) {
/*** this is done for the first fragment ***/
/*** and it's OK ***/
closeText();
pdf.append(1 0 0 -1 + (rx / 1000f) + + (bl / 1000f) + Tm
+ (text.getTSadjust()/1000f) + Tw [ + startText);
prevWordY = bl;
textOpen = true;
} else {
// express the space between words in thousandths of an em
int space = prevWordX - rx + prevWordWidth;
float emDiff = (float) space / (float) currentFontSize * 1000f;
// this prevents a problem in Acrobat Reader and other viewers
// where large numbers cause text to disappear or default to
// a limit
if (emDiff -33000) {
/*** this would be OK, but it is not done ***/
closeText();
pdf.append(1 0 0 -1 + (rx / 1000f) + + (bl / 1000f) + Tm
+ (text.getTSadjust()/1000f) + Tw [ + startText);
textOpen = true;
} else {
/*** this is done for the following fragments ***/
/*** and it is not correct because it uses the***/
/*** space adjustment of the first fragment!! ***/
pdf.append(Float.toString(emDiff));
pdf.append( );
pdf.append(startText);
}
}
...
So the resulting pdf code contains:
... 4.869 Tw [(fragment 1) 0.0 (fragment 2)] TJ
\--/
|
space adjustment for the FIRST fragment
instead of:
... 4.869 Tw [(fragment 1)] TJ
... 1.853 Tw [(fragment 2)] TJ
I have tried to fix this commenting out the if and the else branch, so
that each fragment uses its own space adjustment, and it works.
But the comment says that the if was done to prevent a problem, so I fear that
that problem could arise againg, removing the if.
Luca
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-06 10:36 --- Created an attachment (id=11151) fo file having a line whose text comes from 2 different TextLMs
Re: DO NOT REPLY [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly
On Sun, Apr 04, 2004 at 06:41:41AM -, [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2004-04-04 06:41 --- Anyway, please check the latest solution applied. Here I brought in the old solution to solve the extra spaces problem, while keeping the new solution for the more commonly occurring spaces at the front of fo:text. (As stated above, I suspect 10%), so more optimization may be needed here. (Perhaps an error in my logic of when RemoveA vs. RemoveB should be called.) Comments most welcome. The code seems OK to me. I have a remark on the logic of nextCharCalled. It is equal to curIndex - startIndex. Also, in remove() you should separately consider the case nextCharCalled == 0: it should not happen. I have looked at the output in the area tree (at output). It does not reproduce the error in the first block of my test fo, the one with the colored inline FOs. That may be an error of the PDF renderer. It does reproduce the error in the second block: The second line is longer than in the other blocks, and the last line is dropped. That may be an error in the layout managers. I saw no problem with the logic of RemoveA, RemoveB or RemoveC. RemoveB does handle trailing spaces except for the last one. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly
I should add that I have realized that the rules of whitespace handling in the FO spec are quite complicated, and that it is unwise to handle whitespace outside of the Block.handleWhiteSpace method. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
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-06 12:55 ---
Hi Luca,
Im looking at your patch now. I tried removing the IF statement and the effect
is one part line of text in your 2nd sample is flipped upside down!
Instead I tried keeping the IF statement there, but setting the word spacing
in both bits, e.g.
if (emDiff -33000) {
closeText();
pdf.append(1 0 0 1 + (rx / 1000f) + + (bl / 1000f) +
Tm
+ (text.getTSadjust()/1000f) + Tw [ + startText);
textOpen = true;
} else {
pdf.append(Float.toString(emDiff));
pdf.append( + (text.getTSadjust()/1000f) + Tw );
pdf.append(startText);
}
This is closer, but the justification is very slightly out on the 2nd
paragraph. Ill take another look later. Thanks for all your efforts
Chris
Database #Error
-- Partial message is available! -- Error: llegal signs in Mail-Routing -- Mail Server: ESMTP VX32.9 Version Betha Alpha Norton AntiVirus gelöscht1.txt Description: plain/text
DO NOT REPLY [Bug 28237] New: - [PATCH] Use the commons logging LogFactory also in Fop.java
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=28237. 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=28237 [PATCH] Use the commons logging LogFactory also in Fop.java Summary: [PATCH] Use the commons logging LogFactory also in Fop.java Product: Fop Version: 1.0dev Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Use the commons logging LogFactory also in Fop.java. Do not set the log level, but let that be set by the log implementation's own configuration. For backwards compatibility retain the command line options -d and --full-error-dump, -q and --quiet. These options create a hard-coded SimpleLog instance with the appropriate log level set. For the -x command line option, if debug logging is not enabled, create a hard-coded SimpleLog instance with log level set to debug. With this change the command line logger is also configured according to the commons logging user preferences, and according to the user preferences for the chosen log implementation, like many other loggers in the system. This should be reflected in the instructions. The command line logger is also used by the LM system.
DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java
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=28237. 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=28237 [PATCH] Use the commons logging LogFactory also in Fop.java --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 17:36 --- Created an attachment (id=11157) The patch as described
DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java
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=28237. 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=28237 [PATCH] Use the commons logging LogFactory also in Fop.java --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 21:48 --- Simon, if I understand you correctly (and pardon me, I'm not a logging expert): 1.) With our current process of setting the logger in FOP.java directly, we end up overriding whatever the command-line user may have specified on their machine? (Remember, FOP embedded users set Logging via the Driver class anyway.) 2.) Will FOP still quietly default to SimpleLog if the user doesn't enter anything explicitly? I would guess 95%* of our **command-line** user base either doesn't care about logging, or if they did care they want the command- line output (i.e., SimpleLog) anyway--does your change reflect this? We don't want users practicing with the command line to have to distract themselves with the logger. 3.) As another option for the command-line user, given only a small minority want to log to a file, would it be better to provide a -logfile option, that once specified, logs to that file, and absent the setting of that option, will go quietly go to the SimpleLog? Thanks, Glen
Re: DO NOT REPLY [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly
Thanks for looking through the code, Simon. --- Simon Pepping [EMAIL PROTECTED] wrote: I have a remark on the logic of nextCharCalled. It is equal to curIndex - startIndex. Also, in remove() you should separately consider the case nextCharCalled == 0: it should not happen. nextCharCalled is a terribly named variable--but I haven't thought of anything better. Suggestions welcome for its renaming. The process of moving from RemoveA (where I can just nicely increment the startIndex, i.e., to remove leading spaces) to RemoveB (where I need to start doing arraycopies, e.g., to remove spaces between words) is activated when two or more consecutive nextChar() iterations occur *without* a remove() call in between. This would indicate that we've encountered a valid character, so we've hit a word and now any subsequent space removal has to occur via RemoveB method. Whenever remove() is called during RemoveA time, I just keep resetting it to zero for the logic above to occur. It may not be the best, however, as I mentioned earlier RemoveB appears to be called too soon too often. I'll get all this commented soon in the code. I have looked at the output in the area tree (at output). It does not reproduce the error in the first block of my test fo, the one with the colored inline FOs. That may be an error of the PDF renderer. I'm unsure if this is good news or bad news. ;-) But anyway, more work for us... Glen
Re: [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly
I'm not sure exactly what you mean--are you indicating it might be best to pull out the interators from FOText and flow.Inline and have everything done within flow.Block? That could work well. A further optimization might be to do all this before the Block is even parsed into FOText and Inline objects, as many spaces-only objects would end up not even needing to be created. I was originally thinking of the other direction--instead of all the bouncing code between Block and FOText, just put all the logic in FOText, and have FOText completely responsible for its own whitespace removal. Problem with this though is that we'd have to duplicate the whitespace processing logic into Inline as well, also, there's the issue of whitespace between consecutive FOText and/or Inline objects still needing to be handled. So this probably wouldn't be a good idea. Thanks, Glen --- Simon Pepping [EMAIL PROTECTED] wrote: I should add that I have realized that the rules of whitespace handling in the FO spec are quite complicated, and that it is unwise to handle whitespace outside of the Block.handleWhiteSpace method. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
cvs commit: xml-fop/src/java/org/apache/fop/fo FOText.java
gmazza 2004/04/06 15:50:44
Modified:src/java/org/apache/fop/fo FOText.java
Log:
Comments added.
Revision ChangesPath
1.19 +10 -1 xml-fop/src/java/org/apache/fop/fo/FOText.java
Index: FOText.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOText.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- FOText.java 4 Apr 2004 06:29:44 - 1.18
+++ FOText.java 6 Apr 2004 22:50:44 - 1.19
@@ -443,6 +443,14 @@
private class TextCharIterator extends AbstractCharIterator {
private int curIndex = 0;
+
+/* Current space removal process: just increment the startIndex
+ to remove leading spaces from ca, until an unremoved character
+ is found. Then perform arraycopy's to remove extra spaces
+ between words. nextCharCalled is used to determine if an
+ unremoved character has already been found--if its value 2
+ than it means that has occurred (it is reset to zero each time we
+ remove a space via incrementing the startIndex.) */
private int nextCharCalled = 0;
public boolean hasNext() {
@@ -476,7 +484,8 @@
// System.out.println(removeB: + new String(ca, startIndex,
endIndex - startIndex));
} else if (curIndex == endIndex) {
// System.out.println(removeC: + new String(ca, startIndex,
endIndex - startIndex));
-curIndex = --endIndex;
+endIndex--;
+curIndex--;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
