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-07 07:30 --- Hi The text upside-down depends on a missing - that I forgot to correct in the patch: [then branch of the if] pdf.append(1 0 0 -1 + ... ^^ Now I'm trying to understand what happens with your suggested change. 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-07 12:17 --- Hi Chris, I'm here again. I have done some tests, and it seems to me that a second Tw operand inside the array ... Tm 4 Tw [(first fragment ) 0 1 Tw (second fragment of text)] TJ affects EVERY space in the array, not only the ones in the following string. This is quite counter-intuitive, but you can see this if you look at the pdfs genereted in the two ways we proposed: with your patch it seems that the first space in the second line (which belongs to the first fragment of text) is as long as the other spaces (which belongs to the second fragment), while with mine it is visibly longer. On this subject, I have a few doubts: - is this behaviour (spaces in a same line are sometimes different) acceptable? Surely it is easier, as the LineLM has to compute only one adjustment factor which every TextLMs involved in the line building uses. - if this is ok, then there are problems with fragments of text without spaces (this can happen with the last word before a linefeed treated as space, or the first after); maybe in these cases we could use letter spacing instead of word spacing. 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 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-04-07 14:25 --- Hi Luca, I had another look at your proposal and ive decided its probably okay to delete the IF statement for emDiff -33000. We are keeping the case that is supposed to be the work around for the issue described in the comments. So in theory we shouldnt hit the issue. Ive run a few test cases and the justification seems to work nicely. However there seems to be an outstanding issue of text-align-last. In your test cases, setting text-align=justify does not justify the last line, but in examples\fo\basic\simple.fo, the last lines are justified even though only text-align=justify is specified. For now, Im happy to apply your patch. Thanks
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-07 20:37 --- Glen, SimpleLog log = new SimpleLog(FOP); log.setLevel(SimpleLog.LOG_LEVEL_INFO); driver.setLogger(log); driver.getLogger().info(version); options = new CommandLineOptions(args); This code in Fop.java has three problems: 1. SimpleLog is configured by Java system properties. The second line above overrules that, against reasonable expectations of users. If a user does nothing, SimpleLog selects a reasonable default: info. 2. The command line options -d and -e are used to configure the Log object of the options object. This log is not passed on to driver, and thus gets lost. 3. Commons logging is also configured by Java system properties. A user may configure it to use a certain logging implementation, e.g. Log4J. Hard coding a SimpleLog instance goes against reasonable expectations of users when we advertise that we use commons logging. If a user does nothing he gets the JDK 1.4 logging if he runs that version, and SimpleLog otherwise. I believe that my patch makes Fop's logging behaviour consistent with the claim that we use commons logging, and with the documented configuration options of commons logging. And it makes it consistent internally. Note that Jeremias changed the code of many classes to use commons logging. SimpleLog logs to stderr; only redirection sends it to a file (and that is impossible under MSWindows command and cmd shells). For command-line users that seems appropriate; other users should select and configure a log implementation that suits them. With commons logging configuring logging via command line options is not really appropriate. This is all I discovered. I went into this because I was hit by the inconsistencies in the current logging. For example, currently getlogger().debug(xxx) in FOText.java will not give you anything for the reasons I described under 1 and 2 above. Regards, Simon
Re: [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly
On Tue, Apr 06, 2004 at 03:47:53PM -0700, Glen Mazza wrote: 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. Frankly, I do not mean much. It is just an observation. In my patch I suppressed multiple white space directly in FOText, without regards for the spec. When I followed your code I realized that Block.handleWhiteSpace contains white space removal logic according to the spec, and that it was very wrong to bypass that. I just wanted to note that. I do not think that that logic should be duplicated or moved. There is an inefficiency here, but I do not have any good idea for optimization. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
