Re: Classpath setup problem
J.Pietschmann schrieb: Hi devs, I just upgraded to Ant 1.6.5 and the junit tasks stopped working (see Ant FAQ faq.html#delegating-classloader). I really liked my setup where all jars were in a single directory. :-( Yeah, with the help of those nice build.bat|sh ;-) It's too late in the evening for advanced reshuffling of important libraries. What's your setup? apt-get install ant junit which puts a symlink to junit.jar in /usr/share/ant/lib/ -- Christian
Re: fo:inline bpd
Rather complex area, line building. One that is a little under-present in our testcases so far. I believe you're correct (comments in 4.6 and 7.15.4), but I have the impression that we'd actually need to look at this from a more general angle eventually. Not necessarily right now, of course. But it may be good to start building up test cases and the knowledge on all the advanced aspects of line building. On 06.09.2005 06:57:06 Manuel Mall wrote: Currently fop sets the bpd of areas created from fo:inlines to to line-height of the line the area appears in. For example: fo:block font-size=10ptSome text fo:inline font-size=8ptsmaller text/fo:inline/fo:block The inline parent area created for the fo:inline will be given a bpd of 12pt, i.e. the line-height of the surrounding block, and not 9.6pt which is the height of the fo:inline. The difference is visually noticeable to moment one applies backgrounds or borders/padding to the fo:inline. Am I correct in saying that the current implementation is incorrect and that the smaller bpd should be applied in the example above? Manuel Jeremias Maerki
Re: Classpath setup problem
Just upgraded to Ant 1.6.5 on Windoze. 1. Unpack binaries 2. Adjust ANT_HOME env variable (%ANT_HOME%\bin is already in the PATH) 3. Copy junit-3.8.1.jar into the lib directory of the Ant installation. ...works. On 06.09.2005 00:53:13 J.Pietschmann wrote: Hi devs, I just upgraded to Ant 1.6.5 and the junit tasks stopped working (see Ant FAQ faq.html#delegating-classloader). I really liked my setup where all jars were in a single directory. :-( It's too late in the evening for advanced reshuffling of important libraries. What's your setup? J.Pietschmann Jeremias Maerki
DO NOT REPLY [Bug 36508] - [PATCH] Padding-* attributes handling in RTF-rendering
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=36508. 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=36508 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Padding-* attributes|[PATCH] Padding-* attributes |handling in RTF-rendering |handling in RTF-rendering -- 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: fo:inline bpd
On Tue, 6 Sep 2005 04:02 pm, Jeremias Maerki wrote: Rather complex area, line building. One that is a little under-present in our testcases so far. I believe you're correct (comments in 4.6 and 7.15.4), but I have the impression that we'd actually need to look at this from a more general angle eventually. Not necessarily right now, of course. But it may be good to start building up test cases and the knowledge on all the advanced aspects of line building. I seemed to have a bad run here :-). Whenever I poke my nose into something lately the response seems to be: That's a very difficult subject which needs more investigation... Just joking - please don't take this as a complaint. Yes, the spec says that areas returned from fo:inline have their own line-height trait which can be different to the line-height trait of the line area they belong to. We don't do that currently. At a high level the algorithm seems to look like: Collect all the Knuth sequences. Break them into lines - this also determines the line dimensions (line height, baseline, ...). For each line determine the subsequences which belong to the same child LM and give those to the child LMs for area construction. The problem is that the Inline LM doesn't calculate the dimension of the area it is suppose to construct from the subsequence given to it by the Line LM. Instead it just assumes the dimension of the line as given to it in the LayoutContext. However, to be able to do the required calculations the Inline LM would need access to the KnuthElements of the subsequence it is suppose to construct the area for. However, what's given to it is a sequence of KnuthPositions (the standard addAreas() interface) not elements. Alternatively the Line LM could calculate the dimensions of the line segment the Inline LM is suppose to construct. It may actually be appropriate to do that in the Line LM as it already has the relevant logic. But still we would need an interface to get this across to the Inline LM. On 06.09.2005 06:57:06 Manuel Mall wrote: Currently fop sets the bpd of areas created from fo:inlines to to line-height of the line the area appears in. For example: fo:block font-size=10ptSome text fo:inline font-size=8ptsmaller text/fo:inline/fo:block The inline parent area created for the fo:inline will be given a bpd of 12pt, i.e. the line-height of the surrounding block, and not 9.6pt which is the height of the fo:inline. The difference is visually noticeable to moment one applies backgrounds or borders/padding to the fo:inline. Am I correct in saying that the current implementation is incorrect and that the smaller bpd should be applied in the example above? Manuel Jeremias Maerki Manuel
Re: e-g with padding and borders
Manuel Mall wrote: Next problem: border conditionality - how do I model that with the Knuth approach? At the time I add the Border/Padding start/end boxes we don't have line breaks so they really only cover the .conditionality=discard case. How do I tell the algorithm to leave enough space at the end of each line (and the beginning of the next line) for the borders (in the case of .conditionality=retain)? The sequence of elements representing the inline content starts and ends with a box [1]. Adding another box at the beginning and at the end of the sequence implements retain, as a line break is never allowed to separate two adjacent boxes: so, the left border and padding will always be in same line as the first piece of content, and the breaking algorithm will always reserve enough space. In order to implement discard, glue elements must be used instead: these elements are discarded if they are chosen as a line break or they are adjacent to a line break, and in this case borders and padding will not be painted. I think that a single box or glue element could be created, representing both border and padding, unless the conditionalities of these properties can be different: for example, if it were possible to have border-start.conditionality = discard and padding-start.conditionality = retain two distinct elements should necessarily be created. Regards Luca [1] Or, better, everything should work well if the first and last elements are boxes. Should there be spaces at the beginning and at the end of the inline having borders, they should be handled as non-breaking spaces, in order to avoid a break between the start border and the first word, or between the last word and the end border.
Re: Line LM, Inline LM and LAST_AREA
Manuel Mall wrote: But if we have a long fo:inline stretching multiple lines this seem to give the wrong results from the Inline LM perspective. For example if the fo:inline finishes in the middle of a line followed by more text the Line LM will not set the LAST_AREA flag when calling addAreas on the Inline LM as there are more areas on the line. Therefore the Inline LM thinks its not done with yet although it is and the reverse is true on the first line of a multi-line inline. The LineLM.addAreas() method creates a line at a time (a line for each LineBreakPosition), and asks its children to add their inline areas for the line area being created. It sets the LAST_AREA flag if the child LM is the one that created the last element placed in this line: for each line, there is one and only one child LM that receives a LayoutContext with this flag set, unless there are bugs :-) If the content of an inline is divided among several lines, the method InlineLM.addAreas() will be called once per line, and all the times (but the last) it will have the LAST_AREA flag on. Some time ago there was a thread about a similar subject [1]: the problem, then, was the opposite, i.e. to find out which is the last area generated by a LM, regardless of line breaks. I think there is a bit of ambiguity in the names: at the moment, the LAST_AREA flag signals to a LM that it is adding the last inline area in a line, or the last block area in a page, but this can cause confusion with the is-last area trait described by the specs (4.2.2 Common traits). Maybe we can find out a more significant and univocal name. Regards Luca [1] Markers: Determining the last generated area for a LM, http://nagoya.apache.org/eyebrowse/ReadMsg?listId=63msgNo=11296
Re: e-g with padding and borders
Manuel Mall wrote: These two paragraphs confuse me - sorry. My understanding was: discard = start/end borders/padding only at the start and end of the whole fo:inline retain = as discard plus start/end borders/padding on the start and end of every line the fo:inline spans. Sorry, you are completely right, I did not understand you were referring to the extra borders needed around a line break. What we need is one or more elements whose overall behaviour is this: - they represent a space (or another legal break point) - if they are not used as a break, they behave like a normal space (or like a not-used hyphenation point) - if they are chosen as a break, they must add something both at the end of the line they end, and at the beginning of the next line This is quite similar to the behaviour of the sequence of elements representing a space in a centered text (in the TextLM.getNextKnuthElements() method); so, in this case we could use: 1 glue width = border/padding at the end of the line = A 2 penalty width = 0, value = 0 3 glue width = space.opt - (A + B), stretch = space.max - space.opt shrink = space.opt - space.min 4 box width = 0 5 penalty width = 0, value = infinity 6 glue with = border/padding at the beginning of the line = B so: - element 1 is a legal break point, but it is never chosen as 2 is better - element 2 is a legal break point: if it is chosen, the ending line will reserve a width of A for border and padding, and the next line will reserve a width of B (the glue 3 is discarded) - element 3 is NOT a legal break because of the preceding penalty - element 5 is NOT a legal break because of its value - element 6 is NOT a legal break because of the preceding penalty - is there is no break, the overall width is A + (space.opt - (A + B)) + B = space.opt In order to make all this work, the TextLM should - know that it is working on text with non-conditional borders - combine this sequence with the one it would create in a normal situation Regards Luca
Re: e-g with padding and borders
Luca, thanks great stuff - that gives me a lot to work with. Manuel On Tue, 6 Sep 2005 06:48 pm, Luca Furini wrote: Manuel Mall wrote: These two paragraphs confuse me - sorry. My understanding was: discard = start/end borders/padding only at the start and end of the whole fo:inline retain = as discard plus start/end borders/padding on the start and end of every line the fo:inline spans. Sorry, you are completely right, I did not understand you were referring to the extra borders needed around a line break. What we need is one or more elements whose overall behaviour is this: - they represent a space (or another legal break point) - if they are not used as a break, they behave like a normal space (or like a not-used hyphenation point) - if they are chosen as a break, they must add something both at the end of the line they end, and at the beginning of the next line This is quite similar to the behaviour of the sequence of elements representing a space in a centered text (in the TextLM.getNextKnuthElements() method); so, in this case we could use: 1 glue width = border/padding at the end of the line = A 2 penalty width = 0, value = 0 3 glue width = space.opt - (A + B), stretch = space.max - space.opt shrink = space.opt - space.min 4 box width = 0 5 penalty width = 0, value = infinity 6 glue with = border/padding at the beginning of the line = B so: - element 1 is a legal break point, but it is never chosen as 2 is better - element 2 is a legal break point: if it is chosen, the ending line will reserve a width of A for border and padding, and the next line will reserve a width of B (the glue 3 is discarded) - element 3 is NOT a legal break because of the preceding penalty - element 5 is NOT a legal break because of its value - element 6 is NOT a legal break because of the preceding penalty - is there is no break, the overall width is A + (space.opt - (A + B)) + B = space.opt In order to make all this work, the TextLM should - know that it is working on text with non-conditional borders - combine this sequence with the one it would create in a normal situation Regards Luca
Re: Line LM, Inline LM and LAST_AREA
Luca, thanks. 1. You confirmed what I suspected - LAST_AREA means last area in that line; so may be we should rename it to LAST_AREA_IN_LINE? 2. I need (nearly) exactly what Jeremias was referring to in your [1] - that is an indication that the last area for a LM is being generated. In my case I am only interested in inline areas. However, it seems no solution has yet been found for this issue. I'll keep looking then. Manuel On Tue, 6 Sep 2005 06:46 pm, Luca Furini wrote: Manuel Mall wrote: But if we have a long fo:inline stretching multiple lines this seem to give the wrong results from the Inline LM perspective. For example if the fo:inline finishes in the middle of a line followed by more text the Line LM will not set the LAST_AREA flag when calling addAreas on the Inline LM as there are more areas on the line. Therefore the Inline LM thinks its not done with yet although it is and the reverse is true on the first line of a multi-line inline. The LineLM.addAreas() method creates a line at a time (a line for each LineBreakPosition), and asks its children to add their inline areas for the line area being created. It sets the LAST_AREA flag if the child LM is the one that created the last element placed in this line: for each line, there is one and only one child LM that receives a LayoutContext with this flag set, unless there are bugs :-) If the content of an inline is divided among several lines, the method InlineLM.addAreas() will be called once per line, and all the times (but the last) it will have the LAST_AREA flag on. Some time ago there was a thread about a similar subject [1]: the problem, then, was the opposite, i.e. to find out which is the last area generated by a LM, regardless of line breaks. I think there is a bit of ambiguity in the names: at the moment, the LAST_AREA flag signals to a LM that it is adding the last inline area in a line, or the last block area in a page, but this can cause confusion with the is-last area trait described by the specs (4.2.2 Common traits). Maybe we can find out a more significant and univocal name. Regards Luca [1] Markers: Determining the last generated area for a LM, http://nagoya.apache.org/eyebrowse/ReadMsg?listId=63msgNo=11296
DO NOT REPLY [Bug 36508] - [PATCH] Padding-* attributes handling in RTF-rendering
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=36508. 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=36508 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-06 14:12 --- Applied. Thanks! http://svn.apache.org/viewcvs?rev=278982view=rev Thanks to you padding on before and after sides work well now. A quick test shows that the start|end sides don't quite work as expected. You might want to have a look at it. The following leads to strange results: fo:block margin-left=2cm border=solid 2pt padding-start=2cmHello World!/fo:block -- 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.
ForayFont dependency in graphics commons; was: Logging for FOrayFont
Hi all, So this is a tricky one. I really feel like I'm getting in the way of FOP stuff, but on the other hand as far as I can see the ForayFont stuff would have almost zero advantage for Batik's use of the PDF Transcoder. This is because Batik has to do all of it's own text layout and it currently does this using the Java2D Platform Fonts, TrueType (referenced from CSS), and of course SVG fonts. Right now there are a few 'trivial' text cases that are handled by the PDF Graphics2D 'drawString' stuff that might benefit but basically, as far as I can see, this would - for Batik - be another very low functionality external dependency. That said I know that currently one of the stumbling blocks for extracting the PDFGraphics2D from the rest of FOP is the the font subsystem. There is a bit of an inherent conflict between using Graphics2D as a 'high level transcoding' API and advanced font/text handling. Currently, the list of Java2D fonts (from GraphicsEnvironment is totally independent of the Graphics2D). Now of course the current state of text output for PDF is fairly abysmal from Batik (anything beyond very simple text is done as shapes), but fixing that would probably be a huge piece of work. I personally would lean towards leaving the font-subsystem as pluggable. BTW as far as the PsuedoLogger stuff is concerned this is fine with me (and is actually my preferred way to handle this). It doesn't force any logger on me, yet one can plug it into any existing logging system with a fairly trivial piece of code. Although this may not matter depending on how we approach Font support. Jeremias Maerki wrote: I got a little shock when I realized a problem I didn't think of when we discussed moving FOP components over to XML Graphics Commons. We said we would try to remove logging code from these basic components entirely. Now, I forgot to consider the decision to use FOrayFont made earlier. The external dependency on FOrayFont also would be a problem in itself because the Batik side has strong feelings against external dependencies. We need to think about what to do about this WRT the PDF and PS transcoders. Optimized text painting in these two transcoders depends a lot on the font subsystem. Chris Bowditch wrote: Ouch! The FORayFont integration offers a hugh functional benefit over the current Font code, so it would be a real shame to lose it. IIRC Thomas was saying that he was against dependencies that don't yield any functional benefit, i.e. logging and avalon framework. Since FORayFont does have functional benefits for both projects perhaps it won't be such a problem for Batik to include it. But I guess that is up the Batik team to decide.
Re: Line LM, Inline LM and LAST_AREA
Certainly not, if it solves the problem. Just make certain that it doesn't add up too much on memory consumption on LMs that don't need the position indexes. Maybe this infrastructure should be extracted into its own class and used by the LMs that need it. On 06.09.2005 14:33:07 Manuel Mall wrote: Jeremias any problems if I push this down from BlockStacking LM into Abstract LM so I can make use of it in the Inline LMs? Jeremias Maerki
Re: ForayFont dependency in graphics commons; was: Logging for FOrayFont
Thanks for chiming in, Thomas. It should be possible to have that pluggable for Batik. After all, the text bridge mechanism from Batik provides an ideal way to plug that functionality in. A few random notes on the topic: - The PDF library has dependencies on the font subsystem, so we would need to make sure that Batik without special text handling in PDF will work without the font subsystem classes present in the classpath. - Maybe something could be done to embed the fonts of the Java2D origin as Type 3 fonts. Keiron has left a TODO item about that somewhere. Shouldn't be that hard to do. - There IS benefit in painting text as text instead of shapes. You get a lot of speed and a much smaller file size. - I have the impression that the FOP-grown text bridges currently don't work though I haven't investigated closely, yet. I hope we'll find a good way to handle this. I'll start copying/migrating components over to Commons as soon as the first FOP preview release is out. On 06.09.2005 14:31:38 Thomas DeWeese wrote: Hi all, So this is a tricky one. I really feel like I'm getting in the way of FOP stuff, but on the other hand as far as I can see the ForayFont stuff would have almost zero advantage for Batik's use of the PDF Transcoder. This is because Batik has to do all of it's own text layout and it currently does this using the Java2D Platform Fonts, TrueType (referenced from CSS), and of course SVG fonts. Right now there are a few 'trivial' text cases that are handled by the PDF Graphics2D 'drawString' stuff that might benefit but basically, as far as I can see, this would - for Batik - be another very low functionality external dependency. That said I know that currently one of the stumbling blocks for extracting the PDFGraphics2D from the rest of FOP is the the font subsystem. There is a bit of an inherent conflict between using Graphics2D as a 'high level transcoding' API and advanced font/text handling. Currently, the list of Java2D fonts (from GraphicsEnvironment is totally independent of the Graphics2D). Now of course the current state of text output for PDF is fairly abysmal from Batik (anything beyond very simple text is done as shapes), but fixing that would probably be a huge piece of work. I personally would lean towards leaving the font-subsystem as pluggable. BTW as far as the PsuedoLogger stuff is concerned this is fine with me (and is actually my preferred way to handle this). It doesn't force any logger on me, yet one can plug it into any existing logging system with a fairly trivial piece of code. Although this may not matter depending on how we approach Font support. Jeremias Maerki wrote: I got a little shock when I realized a problem I didn't think of when we discussed moving FOP components over to XML Graphics Commons. We said we would try to remove logging code from these basic components entirely. Now, I forgot to consider the decision to use FOrayFont made earlier. The external dependency on FOrayFont also would be a problem in itself because the Batik side has strong feelings against external dependencies. We need to think about what to do about this WRT the PDF and PS transcoders. Optimized text painting in these two transcoders depends a lot on the font subsystem. Chris Bowditch wrote: Ouch! The FORayFont integration offers a hugh functional benefit over the current Font code, so it would be a real shame to lose it. IIRC Thomas was saying that he was against dependencies that don't yield any functional benefit, i.e. logging and avalon framework. Since FORayFont does have functional benefits for both projects perhaps it won't be such a problem for Batik to include it. But I guess that is up the Batik team to decide. Jeremias Maerki
DO NOT REPLY [Bug 36520] New: - [PATCH] Java2DSVGHandler
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=36520. 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=36520 Summary: [PATCH] Java2DSVGHandler Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: svg AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] In response to http://issues.apache.org/bugzilla/show_bug.cgi?id=36505, jeremias wrote: ...I'm not happy with the current state of Java2DRenderer.renderSVGDocument(). Creating inverse transformation matrices is surely not the right way to do this. The matrix should be saved and restored instead.Furthermore, renderSVGDocument should be extracted into a Java2DSVGHandler like it is done for the other renderers. This patch fixes both these issues. -- 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 36520] - [PATCH] Java2DSVGHandler
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=36520. 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=36520 --- Additional Comments From [EMAIL PROTECTED] 2005-09-06 15:39 --- Created an attachment (id=16317) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16317action=view) Adds new Java2DSVGHandler class -- 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 36508] - [PATCH] Padding-* attributes handling in RTF-rendering
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=36508. 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=36508 --- Additional Comments From [EMAIL PROTECTED] 2005-09-06 15:48 --- (In reply to comment #2) Applied. Thanks! http://svn.apache.org/viewcvs?rev=278982view=rev Thanks to you padding on before and after sides work well now. A quick test shows that the start|end sides don't quite work as expected. You might want to have a look at it. The following leads to strange results: fo:block margin-left=2cm border=solid 2pt padding-start=2cmHello World!/fo:block Yes, it's quite strange. But now I can't resolved it, because if border specified, then padding should be in range [0..31] pt. I use MSWord as RTF- viewer. In above test padding was greater then 31 pt, so it was cutted. -- 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 36520] - [PATCH] Java2DSVGHandler
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=36520. 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=36520 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-06 16:24 --- Applied. Thanks! That was fast!!! :-) http://svn.apache.org/viewcvs?rev=279005view=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.
DO NOT REPLY [Bug 36508] - [PATCH] Padding-* attributes handling in RTF-rendering
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=36508. 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=36508 --- Additional Comments From [EMAIL PROTECTED] 2005-09-06 16:33 --- Do you have a reference to a document that describes this restriction? I've looked through versions 1.7 and 1.8 of Microsoft's RTF specification but have found nothing. Maybe it's possible to warn the user that there will be unexpected behaviour when such a constellation is encountered. -- 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: Line LM, Inline LM and LAST_AREA
Hey, its nearly midnight and time to get some sleep - but have to share this: had some success with this refactoring - attached a PDF and the FO file showing how much of the inline border / padding stuff now works. The nested inlines are not 100% right yet, still need to figure out a fix for the incorrect inline box sizes and of course the conditionality=retain (but thanks to Luca I have an idea how to tackle that). Manuel On Tue, 6 Sep 2005 08:47 pm, Jeremias Maerki wrote: Certainly not, if it solves the problem. Just make certain that it doesn't add up too much on memory consumption on LMs that don't need the position indexes. Maybe this infrastructure should be extracted into its own class and used by the LMs that need it. On 06.09.2005 14:33:07 Manuel Mall wrote: Jeremias any problems if I push this down from BlockStacking LM into Abstract LM so I can make use of it in the Inline LMs? Jeremias Maerki inline_border_padding.xml.pdf Description: Adobe PDF document ?xml version=1.0 encoding=UTF-8? !-- Copyright 2005 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- $Id: block_border_padding.xml 265720 2005-09-01 13:29:28Z jeremias $ -- testcase info p This test checks inlines with border and padding properties. /p /info fo fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; fo:layout-master-set fo:simple-page-master master-name=normal page-width=5in page-height=5in fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true fo:flow flow-name=xsl-region-body font-size=10pt fo:block margin=0pt background-color=orange Demonstrates various uses of fo:inline !--fo:inline font-size=smaller background-color=yellowstart fo:inlinefo:blockblock/fo:blockfo:inline cont/fo:inline --with borders and padding. /fo:block fo:block background-color=silver margin=2pt 0pt 2pt 0pt To fo:inline border=solid 1pt red background-color=yellowemphasize/fo:inline a word we give it a 1pt border and a background. /fo:block fo:block background-color=silver margin=10pt 0pt 10pt 0pt Demonstrates a big border fo:inline border=solid 5pt red padding=5pt background-color=yellowinline with border=solid 5pt red padding=5pt/fo:inline extending over the small allocation rectangle to the top and bottom. /fo:block fo:block background-color=silver margin=10pt 0pt 10pt 0pt Demonstrates fo:inline border-style=solid border-width=1pt 2pt 3pt 4pt border-color=red padding=1pt 2pt 3pt 4pt background-color=yellowunsymmetric borders and padding/fo:inline but the baselines should align. /fo:block fo:block background-color=silver margin=10pt 0pt 10pt 0pt font-size=20pt Big border fo:inline border=solid 5pt red padding=5pt background-color=yellow font-size=8ptbut a smaller font. This rectangle is/fo:inline incorrect!! /fo:block fo:block background-color=silver margin=3pt 0pt 3pt 0pt This demonstrates a long inline fo:inline border=solid 1pt red padding=1pt background-color=yellowwith .conditionality set to discard. It has a left and right border at the beginning of the and the end of the inline only. Any lines in between only have a top and bottom border./fo:inline Back to normal here. /fo:block fo:block background-color=silver margin=3pt 0pt 3pt 0pt This demonstrates correct line breaking of lt;fo:inlinegt; as this fits exactly on a line. This demonstrates correct line breaking of lt;fo:inlinegt; as this fits exactly on a fo:inline border=solid 1pt red padding-start=2pt padding-end=2pt background-color=yellowline. Not really as we started a fo:inline with border/padding just before the word line which forces it to the next line./fo:inline /fo:block fo:block background-color=silver margin=3pt 0pt 3pt 0pt Demonstrates nested fo:inline border=solid 2pt red padding-start=2pt padding-end=2pt background-color=yellowinlines fo:inline border=solid 1pt green padding-start=2pt padding-end=2pt background-color=orangefinishing together /fo:inline /fo:inline /fo:block /fo:flow /fo:page-sequence
Re: [VOTE] Manuel Mall as new FOP committer
Jeremias Maerki wrote: Manuel Mall has been investing a tremendous amount of time and effort into making FOP better lately. The results were just great. It's been a pleasure to apply his patches, even though it ate up a lot of my time. ;-) Manuel has been around since at least late 2002, even submitted a patch back then. He shows a good understanding of how things work in our project and is quick to learn in other areas. He doesn't fear diving into the code of the layout engine. That's exactly the sort of people we need in the project team. That's why I'd like to nominate him for committership in Apache FOP. +1 from me. J.Pietschmann
Re: Classpath setup problem
Jeremias Maerki wrote: 3. Copy junit-3.8.1.jar into the lib directory of the Ant installation. Yeah, this is exactly what I like to avoid: If I kill the installation, there's a chance all jars put there are gone and have to be extracted from offline archives in the new installation. I'll probably move all jars to ~/.ant/lib and point optional.lib.dir there. Grmbl. J.Pietschmann
User config file currently discarded
Hi, By trying to debug my FOrayFont adaptation I noticed that the user config file currently isn't taken into account by the Trunk. The apps.FOUserAgent.getConfig() method is actually never called within the code, and (as a consequence I suppose) neither is the PDFRenderer.configure(Configuration) method, whose purpose is among other things to register fonts specified in the user config file. Is there a particular reason for this situation? A simple fix would be to call configure within the AbstractRenderer.setUserAgent method, where we can get the user config file associated with the UserAgent given as parameter. This is perhaps not the right place to do that? But if it's ok I can provide a patch. Vincent
Re: Build error
On Mon, Sep 05, 2005 at 11:14:09PM +0200, Jeremias Maerki wrote: Weird, why does it want Service? I've added SubInputStream and all runs through. Thanks. I do not mean that it requires Service. I mean that those two classes are in util and not in the transcoder jars. Simon On 05.09.2005 22:17:41 Simon Pepping wrote: On Mon, Sep 05, 2005 at 09:21:09PM +0200, Jeremias Maerki wrote: You can't, I can. My fault, sorry. http://svn.apache.org/viewcvs?rev=278816view=rev Thanks, that works. Another error, in junit: [junit] Testcase: testGenericPDFTranscoder(org.apache.fop.BasicPSTranscoderTestCase): Caused an ERROR [junit] org/apache/fop/util/SubInputStream [junit] java.lang.NoClassDefFoundError: org/apache/fop/util/SubInputStream Indeed, fop-transcoder.jar and fop-transcoder-allinone.jar do not contain Service and SubInputStream in the util package. Simon -- Simon Pepping home page: http://www.leverkruid.nl Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
Re: Line LM, Inline LM and LAST_AREA
On Tue, Sep 06, 2005 at 12:46:19PM +0200, Luca Furini wrote: Manuel Mall wrote: I think there is a bit of ambiguity in the names: at the moment, the LAST_AREA flag signals to a LM that it is adding the last inline area in a line, or the last block area in a page, but this can cause confusion with the is-last area trait described by the specs (4.2.2 Common traits). Maybe we can find out a more significant and univocal name. I think I have used it in the meaning of is-last trait, back in January, before the page breaking algorithm was applied. I see that BlockStackingLM now uses isFirst(Pos) and isLast(Pos). I am not sure why this LM introduces the methods; every LM needs to be able to mark its areas as first or last, is it not? Anyway, I have always felt that this needed a review as it seemed to be implemented in a patchy manner. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: User config file currently discarded
Actually, everything is fine with the code. The renderer is already configured through the RendererFactory. I assume the problem is the changed format of the userconfig.xml file. I've attached a demo file. Note that each renderer has its own font setup now, mostly because every renderer may have slightly different config values. PS, for example, although it supports the same font subsystem, doesn't support the same filter list config. BTW, the filter setup in the demo file shows how to set the normal stream filter so page streams are not compressed and can easily be inspected in a text editor. Note that if you construct the renderer yourself and supply it through the FOUserAgent, you need to call the configure method yourself. This can easily be done through Avalon's ContainerUtil helper: ContainerUtil.configure(renderer, cfg.getChild(pdf-renderer)); This also handles cases in which the Renderer doesn't implement the Avalon Configurable interface and thus does not support configuration through this means. HTH On 06.09.2005 22:05:27 Jeremias Maerki wrote: No particular reason, no. It's just some missing integration work. I'm configuring my renderer instances directly so I haven't used the FOUserAgent for that. If it's ok for you I'll quickly look into it right now and see what I can do. Actually, I wouldn't want to call configure during setUserAgent(). I will probably do that in the RendererFactory to have a central place to do that. On 06.09.2005 21:45:12 Vincent Hennebert wrote: Hi, By trying to debug my FOrayFont adaptation I noticed that the user config file currently isn't taken into account by the Trunk. The apps.FOUserAgent.getConfig() method is actually never called within the code, and (as a consequence I suppose) neither is the PDFRenderer.configure(Configuration) method, whose purpose is among other things to register fonts specified in the user config file. Is there a particular reason for this situation? A simple fix would be to call configure within the AbstractRenderer.setUserAgent method, where we can get the user config file associated with the UserAgent given as parameter. This is perhaps not the right place to do that? But if it's ok I can provide a patch. Vincent Jeremias Maerki Jeremias Maerki userconfig.xml Description: Binary data
Re: Logging for FOrayFont
On Mon, Sep 05, 2005 at 09:35:26PM +0200, Jeremias Maerki wrote: As I said, widely differing views between Batik and FOP about this. In my own personal opinion, I'm with you. From the POV of XML Graphics Commons we have a problem. We've voted on the plan for Commons where we said that we'd try to remove the dependency on Commons Logging. If there is a problem with that, the right place to raise this is [EMAIL PROTECTED] That means that those Commons components will have to define their own interface to which they are willing to send logging events, just like ForayFont does. FOP will have to implement all interfaces defined by the libraries it uses. It should do so on top of a Commons Logger instance, to preserve Commons Logging user configurability. It would of course be easier if all components would use a standard interface like Commons Logging. But that is not going to happen in this world. My remark about runtime information to debug a system configuration is inspired by a TeX system, which needs to load many component files. I realized that it uses a different method. Its resolver library does indeed no logging. Instead, there is a stand-alone front end to it that the user must run separately to obtain configuration debugging information. For example, when in my LaTeX run class X is not loaded as I expect, I use this app (kpsewhich) to find out where the resolver library thinks the class X is. It also displays search path information, and information about how the search path is constructed from the configuration file and the built in path components. Regards, Simon On 05.09.2005 21:15:50 Simon Pepping wrote: snip/ I am not sure that I understand everything that is being said here. But I am alarmed when I hear that basic libraries, in this case the FontServer, shouldn't log anymore. In my experience a font system requires powerful logging, in order to expose runtime behaviour to the systems manager or end user. Configuring font systems and understanding why a piece of font software does not use it as you expect, is a hard task that requires suitable runtime information from the software. Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
Re: Classpath setup problem
Simon Pepping wrote: I used to use a script for ant that adds junit.jar to the classpath. Since Debian Sarge, it works out of the box, as Christian said. Thanks for the encouragement. After another round of getting the long, well meaning and utterly useless Ant messsage about a task not found, this time because Cygwin $HOME is not Java user.home and therefore ~/.ant/lib isn't searched for jars, I finally solved this by adding -lib ~/java/lib to ANT_ARGS, thereby also making the setting of optional.lib.dir in build-local.properties obsolete. My .antrc is now more than 50 lines! Next question: I used to have old (maintenance branch) jars for FOP and Batik in the repository, which causes compilation problems. Therefore it might be a good idea to include only specific fles rather than *.jar in the classpath set. WDYT? J.Pietschmann
RE: Logging for FOrayFont
Simon Pepping wrote: It would of course be easier if all components would use a standard interface like Commons Logging. But that is not going to happen in this world. FWIW, I am not opposed to having FOray use Commons Logging instead of a home-grown interface. But that is actually an external dependency as well, so that was not an option. And from the standpoint of a component developer, you have to ask yourself how often you can afford to switch from Avalon to Commons to ... It would (maybe) help some if java itself would endorse an interface for this purpose. Victor Mote
DO NOT REPLY [Bug 36533] New: - Incorrect ipd and twsadjust settings
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=36533. 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=36533 Summary: Incorrect ipd and twsadjust settings Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Something is not right with both twsadjust and ipd settings under certain line breaking conditions. I'll attach a testcase showing the problem. I admit I am a bit out of my depth in this area of the code (Line LM - Line Breaking). If someone else please could have a look. The problems as I see them: 1. On the text area in the first fo:block the twsadjust value is set to -897 resulting in the output being more squished than necessary. No other text areas in the example have a non zero twsadjust value. This also leads to different rendering of this line than the corresponding lines in the next two fo:blocks. 2. The second text areas in the second and third fo:block, that is the text areas for the string and right border at the beginning of the and the end of the inline only. Any lines are given an ipd bigger than the line area they belong to. While that is not visible in the output (PDF renderer) for the second fo:block on third block one can see it as the inlineparent also has been given an ipd wider than the line area. -- 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 36533] - Incorrect ipd and twsadjust settings
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=36533. 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=36533 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 04:50 --- Created an attachment (id=16321) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16321action=view) Testcase xml file - no sensible checks yet -- 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 36533] - Incorrect ipd and twsadjust settings
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=36533. 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=36533 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 04:51 --- Created an attachment (id=16322) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16322action=view) The area tree generated from the testcase -- 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.
