letter-spacing
Still trying to fix my problem with letter-spacing and fixed width spaces. Do I understand that correctly that XSL-FO's view of letter-spacing is different than, say, PDF's? PDF's character spacing (PDF 1.4, 5.2.1) is designed so it advances the cursor for each (!) character by the Tc value. FO on the other side applies half the letter-spacing value on the start and end side of the glyph, and only for the characters that are classified as Alphabetic by Unicode. And I don't even say anything about setting precendence and conditionality to anything else than the default. The weird thing about this definition in FO is that these spaces are added (by default) in every case, i.e. even at the beginning of a line: (|=line boundaries, _=spaces generated by letter-spacing) (The text text text text is used with text-align-last=justify here) letter-spacing=normal: |text text text| (Note: FOP does have the permission by the FO spec to increase the inter-character gap here but we don't right now.) letter-spacing=1pt: |_t__e__x__t_ _t__e__x__t_ _t__e__x__t_| PDF's character spacing would work like this, I think (although the last character space needs to be eliminated by the layout manager [1]): |t__e__x__t__ __t__e__x__t__ t__e__x__t|(__) -- [1] If I'm right here (not really sure, that's why I'm asking), it would mean that we should probably stop using the Tc feature from PDF and instead control the glyph positioning ourselves like we already do in PostScript. WDYT? Jeremias Maerki
AW: RTF export enhancement
Jeremias Maerki wrote: Point 3: Yes, for tables, you will somehow need to keep track of the various columns. I don't know the details of the current table support in RTF in detail so I can't help off-hand. Maybe Peter Herweg can help some more. Currently the class TableContext keeps track of the various columns. It's also responsible for cell-spannings and widths. Kind regards, Peter Herweg
Re: letter-spacing
Jeremias Maerki wrote: Still trying to fix my problem with letter-spacing and fixed width spaces. Do I understand that correctly that XSL-FO's view of letter-spacing is different than, say, PDF's? PDF's character spacing (PDF 1.4, 5.2.1) is designed so it advances the cursor for each (!) character by the Tc value. Yes, I remember that when I was working on letter spacing it took me a while to understand what was wrong with the resulting pdf! :-) letter-spacing=1pt: |_t__e__x__t_ _t__e__x__t_ _t__e__x__t_| At the moment, fop has |t__e__x__t t__e__x__t t__e__x__t| in other words there are letter spaces only between letters, and not between a letter and a space. The recommendation states that The algorithm for resolving the adjusted values between word spacing and letter spacing is User Agent dependent. (7.17.2 in the candidate recommendation), so I think this is not a wrong behaviour: it just assumes that word spaces have a higher precedence than letter spaces. Another little difference: each letter space depends on the preceding letter size, instead of depending on both the preceding and following letters sizes; but this has some visible effect only when a word is composed of letters having different sizes. PDF's character spacing would work like this, I think (although the last character space needs to be eliminated by the layout manager [1]): |t__e__x__t__ __t__e__x__t__ t__e__x__t|(__) -- [1] This is why the word spacing adjustment stored in the textAreas is not the computed one, but is specifically modified in order to counterbalance the 2 letter spaces that the pdf will add. If I'm right here (not really sure, that's why I'm asking), it would mean that we should probably stop using the Tc feature from PDF and instead control the glyph positioning ourselves like we already do in PostScript. WDYT? As long as we have just two character categories (letter / spaces) the two pdf operators were enough. Now, with fixed width spaces too, which should be unaffected by the both word spacing (such being different from spaces) and letter spacing (differing from normal letters), two operators are too few. I don't think we need to set the horizontal positioning of each character or word, but just fix the placement of a character sequence following a fixed width space, removing the letter spaces wrongly added by the Tc operator, alternating character sequences and horizontal adjustments in the TJ array. HTH Regards Luca
Re: letter-spacing
On 01.03.2006 15:30:09 Luca Furini wrote: Jeremias Maerki wrote: Still trying to fix my problem with letter-spacing and fixed width spaces. Do I understand that correctly that XSL-FO's view of letter-spacing is different than, say, PDF's? PDF's character spacing (PDF 1.4, 5.2.1) is designed so it advances the cursor for each (!) character by the Tc value. Yes, I remember that when I was working on letter spacing it took me a while to understand what was wrong with the resulting pdf! :-) letter-spacing=1pt: |_t__e__x__t_ _t__e__x__t_ _t__e__x__t_| Hey, I'm again making a complete fool of myself. Mr. Space-Resolution doesn't get the simplest of rules right. Of course, the first and the last space is removed due to conditionality=discard (starts/ends a reference area). So it must actually be: |t__e__x__t_ _t__e__x__t_ _t__e__x__t| Grrr. At the moment, fop has |t__e__x__t t__e__x__t t__e__x__t| in other words there are letter spaces only between letters, and not between a letter and a space. Yes, so even correcting my example we have a difference left to what the spec says. The recommendation states that The algorithm for resolving the adjusted values between word spacing and letter spacing is User Agent dependent. (7.17.2 in the candidate recommendation), so I think this is not a wrong behaviour: it just assumes that word spaces have a higher precedence than letter spaces. No, actually in both cases the precedence is force so all spaces survive the resolution process. Another little difference: each letter space depends on the preceding letter size, instead of depending on both the preceding and following letters sizes; but this has some visible effect only when a word is composed of letters having different sizes. Right. PDF's character spacing would work like this, I think (although the last character space needs to be eliminated by the layout manager [1]): |t__e__x__t__ __t__e__x__t__ t__e__x__t|(__) -- [1] This is why the word spacing adjustment stored in the textAreas is not the computed one, but is specifically modified in order to counterbalance the 2 letter spaces that the pdf will add. If I'm right here (not really sure, that's why I'm asking), it would mean that we should probably stop using the Tc feature from PDF and instead control the glyph positioning ourselves like we already do in PostScript. WDYT? As long as we have just two character categories (letter / spaces) the two pdf operators were enough. Now, with fixed width spaces too, which should be unaffected by the both word spacing (such being different from spaces) and letter spacing (differing from normal letters), two operators are too few. I don't think we need to set the horizontal positioning of each character or word, but just fix the placement of a character sequence following a fixed width space, removing the letter spaces wrongly added by the Tc operator, alternating character sequences and horizontal adjustments in the TJ array. HTH It does. Thanks. Means I'm not on the wrong track. However, while I was out for a few hours I was thinking about this and I came to the conclusion that it may make sense to keep an array of character offsets as an attribute of a WordArea in the area tree. Different reasons: - The layout manager already knows exactly where each character should go. At the moment we're somewhat mapping that knowledge into generic properties and the renderer has to reproduce the effect. There's a potential source for errors here. - When at one point we go into details of letter-spacing and word-spacing, this will get more important and most of all more complicated. - The renderer code for text becomes simpler if it simply can use the relative offsets from the area tree. This change doesn't have to happen right now, but it may be worth keeping in mind for later. I think we can still live with a few simplifications for now. Jeremias Maerki
Re: letter-spacing
Jeremias Maerki wrote: The recommendation states that The algorithm for resolving the adjusted values between word spacing and letter spacing is User Agent dependent. (7.17.2 in the candidate recommendation), so I think this is not a wrong behaviour: it just assumes that word spaces have a higher precedence than letter spaces. No, actually in both cases the precedence is force so all spaces survive the resolution process. So, just to check I understood: - according to the pdf specifications between two words there is 1 word space + 2 letter spaces - according to the xsl recommendation there is 1 word space + 1 letter space (or better, two half letter spaces) - fop currently puts just a word space Is this correct? But I still don't understand what the words concerning adjusted values between word spacing and letter spacing are supposed to mean ... However, while I was out for a few hours I was thinking about this and I came to the conclusion that it may make sense to keep an array of character offsets as an attribute of a WordArea in the area tree. It would probably be the best way to deal with kerning too. My only concern is about the resulting pdf size: if we specify an offset for each character, wouldn't it become (at least) twice as big as before? Regards Luca
Re: letter-spacing
On 01.03.2006 16:44:39 Luca Furini wrote: Jeremias Maerki wrote: The recommendation states that The algorithm for resolving the adjusted values between word spacing and letter spacing is User Agent dependent. (7.17.2 in the candidate recommendation), so I think this is not a wrong behaviour: it just assumes that word spaces have a higher precedence than letter spaces. No, actually in both cases the precedence is force so all spaces survive the resolution process. So, just to check I understood: - according to the pdf specifications between two words there is 1 word space + 2 letter spaces 1 ls + 1 ws + 1 ls, yes. - according to the xsl recommendation there is 1 word space + 1 letter space (or better, two half letter spaces) yes, more or less. Even the word space is separated into two halves. - fop currently puts just a word space yes Is this correct? But I still don't understand what the words concerning adjusted values between word spacing and letter spacing are supposed to mean ... I've been wondering about that, too. The user agent has some freedom about choosing default letter and word spacing. The letter- and word-spacing properties specify spaces in addition to the default spaces. Maybe this applies to the default spacing. If you just take the space traits generated by the spacing properties, then it's clear that the normal space-resolution rules apply. Hmm. However, while I was out for a few hours I was thinking about this and I came to the conclusion that it may make sense to keep an array of character offsets as an attribute of a WordArea in the area tree. It would probably be the best way to deal with kerning too. That's one of my next topics. It's actually another reason why I thought about this. Just forgot to list it. My only concern is about the resulting pdf size: if we specify an offset for each character, wouldn't it become (at least) twice as big as before? I don't think it gets twice as big, but yes, we could not use the more space-efficient commands anymore in that case. But it's only plain text which is easily compressed with the Flate algorithm. Jeremias Maerki
DO NOT REPLY [Bug 38821] New: - The manifest file no longer has a Class-Path entry
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=38821. 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=38821 Summary: The manifest file no longer has a Class-Path entry Product: Fop Version: 0.91 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] The manifest file no longer has a Class-Path entry. Why is this? Now it is no longer possible to run FOP with java -jar fop.jar or to launch another application this way that refers to fop.jar in its manifest file. Version 0.20.5 did have such an entry, but the error there was that fop.jar resided in the build directory, while the other JARs were in the lib directory. The fop.jar manfest file, however, expected to be a sibling of the others. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 38821] - The manifest file no longer has a Class-Path entry
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=38821. 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=38821 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2006-03-01 18:18 --- Right, the Class-Path entry has been removed. The Main-Class entry is still there. As compensation for removing the very static Class-Path entry the main class has been extended to dynamically build the right classpath for FOP taking all JAR files in the lib directory into account not only the ones in the Class-Path list. So, this is not a bug, but a feature. :-) Did you actually try running java -jar fop.jar? It works fine for me. If it doesn't for you, please reopen the issue and tell me what the problems are so I can have a look. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 38821] - The manifest file no longer has a Class-Path entry
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=38821. 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=38821 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2006-03-01 18:31 --- If you into the build directory it works, but from anywhere else it doesn't: java -jar file:/var/local/fop-0.91beta/build/fop.jar in my home directory gives: Unable to start FOP: java.lang.RuntimeException: fop.jar not found in directory: /home/werner (or below) at org.apache.fop.cli.Main.getJARList(Main.java:58) at org.apache.fop.cli.Main.startFOPWithDynamicClasspath(Main.java:118) at org.apache.fop.cli.Main.main(Main.java:202) The second problem is that another tool can't refer to fop.jar by putting it in the Class-Path entry of its manifest file. It doesn't matter if you are in the build directory or not. In my opinion the regular extension mechanism should be used. There is nothing static about it. This is a build matter where you keep the manifest file up-to-date when you produce a consistent distribution. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 38821] - The manifest file no longer has a Class-Path entry
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=38821. 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=38821 --- Additional Comments From [EMAIL PROTECTED] 2006-03-01 18:35 --- That looks like a malformed URL to me. Have you tried it this way? java -jar file:///var/local/fop-0.91beta/build/fop.jar -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 38821] - The manifest file no longer has a Class-Path entry
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=38821. 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=38821 --- Additional Comments From [EMAIL PROTECTED] 2006-03-01 18:45 --- The -jar option expects a file not a URL. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users))
On Mar 1, 2006, at 08:46, [EMAIL PROTECTED] wrote: You changed the Writer.write to StringBuffer operations. I'd say that appending to a StringBuffer is much slower than writing directly to a BufferedOutputStream. There was a comparison between static concatenation, concatenation of Strings (variables) during runtime and appending characters to a StringBuffer. I don't remember the factor, but it was significant. Afterall RTF-export is not time critic and runs smooth and maybe the usage of StringBuffer.append is encouraged (due to incredible speed up in newer SDKs...whatever)...any comments? Really? Well, I have to admit, this was a late-night idea :-/ Maybe we could make sure the Writer is wrapped into a BufferedWriter when creating it in RTFHandler, just to streamline a bit. I'd drop that static Map anyways. Makes sense if you need the same constant in a hundred different places, but since all remains private to that tiny class here, they could as well be hardcoded. Work directly on the char primitive instead of the Character object as much as possible. (?) Cheers, Andreas
DO NOT REPLY [Bug 38821] - The manifest file no longer has a Class-Path entry
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=38821. 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=38821 --- Additional Comments From [EMAIL PROTECTED] 2006-03-01 20:13 --- (In reply to comment #2) If you into the build directory it works, but from anywhere else it doesn't: java -jar file:/var/local/fop-0.91beta/build/fop.jar in my home directory gives: Unable to start FOP: java.lang.RuntimeException: fop.jar not found in directory: /home/werner (or below) at org.apache.fop.cli.Main.getJARList(Main.java:58) at org.apache.fop.cli.Main.startFOPWithDynamicClasspath(Main.java:118) at org.apache.fop.cli.Main.main(Main.java:202) Ok, I see the problem. Turns out there really is a downside to my approach. I have no way of retrieving the location of fop.jar without resorting to accessing Sun-specific classes (sun.misc.Launcher). Too bad however, that the Class-Path approach is also flawed. That's why I actually implemented the dynamic class path approach. The second problem is that another tool can't refer to fop.jar by putting it in the Class-Path entry of its manifest file. It doesn't matter if you are in the build directory or not. Just curious: What's the use case here? In my opinion the regular extension mechanism should be used. There is nothing static about it. This is a build matter where you keep the manifest file up-to-date when you produce a consistent distribution. You mean I should revert the change? I guess there's no harm if I simply add the Class-Path entry again. The dynamic approach is only triggered if either Batik or Avalon-Framework is not found in the class path. Any other opinions, fop-devs? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 38821] - The manifest file no longer has a Class-Path entry
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=38821. 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=38821 --- Additional Comments From [EMAIL PROTECTED] 2006-03-01 20:23 --- The second problem is that another tool can't refer to fop.jar by putting it in the Class-Path entry of its manifest file. It doesn't matter if you are in the build directory or not. Just curious: What's the use case here? This is part of the extension mechanism. One JAR can declare the classpath it needs, without needing a global classpath. If you have several JARS with their own dependencies on a classpath, the builder of the global classpath would require all that knowledge and the global classpath might have conflicts for several of the classpaths. Sometimes it is not even possible to rely on a global classpath, in an EAR file for example. Security is another use case. Think of the sandbox. My personal use case is CSSToXSLFO (http://www.re.be/css2xslfo), which has a package variant for FOP. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 38821] - The manifest file no longer has a Class-Path entry
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=38821. 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=38821 --- Additional Comments From [EMAIL PROTECTED] 2006-03-01 21:50 --- Werner, would you please check if my change works for you now? http://svn.apache.org/viewcvs?rev=382152view=rev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
