Re: Margins and writing mode
margin-left always stays on the left side. The FO spec makes a clear distinction between absolute (left, top, right, bottom) and relative (start, end, before, after) properties. lr: left=start, right=end rl: left=end, right=start So you obviously hit a bug. We haven't paid so much attention to the different writing modes, yet, especially since we don't support any of the other writing modes. For me personally, the main reason is the lack of knowledge about non-latin languages. On 30.08.2005 07:02:57 Manuel Mall wrote: If I set the writing mode on a page master to rl (arabic/hebrew) and than define margin-left and right on the region body where are these margins suppose to appear on the output device, i.e. would margin-left still be on the left side of the paper and margin-right on the right side? A sample fo is further below. My problem is that on the generated PDF the margin-left is on the right and vice versa. And I am not sure if that is correct. Manuel 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=3in page-height=5in margin=18pt writing-mode=rl fo:region-body margin-top=18pt margin-bottom=12pt margin-left=15pt margin-right=36pt background-color=yellow / fo:region-before extent=18pt background-color=blue precedence=true / fo:region-after extent=12pt background-color=green precedence=true / fo:region-start extent=36pt background-color=red / fo:region-end extent=15pt background-color=orange / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true fo:static-content flow-name=xsl-region-before fo:block r e g i o n b e f o r e /fo:block /fo:static-content fo:static-content flow-name=xsl-region-after fo:block r e g i o n a f t e r /fo:block /fo:static-content fo:static-content flow-name=xsl-region-start fo:block r e g i o n s t a r t /fo:block /fo:static-content fo:static-content flow-name=xsl-region-end fo:block r e g i o n e n d /fo:block /fo:static-content fo:flow flow-name=xsl-region-body fo:block Demonstrates an 18pt margin on the page master. The page size is 5in x 3in. On the region body we have: margin-top=18pt margin-bottom=12pt margin-left=15pt margin-right=36pt. /fo:block /fo:flow /fo:page-sequence /fo:root Jeremias Maerki
Re: Truncation vs rounding
I think the problem in this area is much less of a problem that within the renderers. The LMs operate on millipoints which provide a very good resolution for our purposes. I doubt we have a big problem here. But in case you find a mixture of approaches, i.e. rounding and truncating, then something needs to be done about it. On the other side rounding is certainly better though I doubt it makes a big difference. And if it's changed it needs be done consistently everywhere. I'd leave it for now. Other opinions? On 30.08.2005 08:24:01 Manuel Mall wrote: In the property system most numeric values are stored and operated upon as double's. However, once we get to the LMs they only deal in int's. Currently the conversion between the double and the int is a simple typecast which equates to truncation. It that the right thing to do or shall we round? Manuel Jeremias Maerki
Re: FOP extension to output custom PostScript instructions
On 30.08.2005 01:24:07 Stephen Denne wrote: Jeremias Maerki wrote: So please help us with the development or at least share with us your concrete requirements! Maybe yours are different than mine. I was intending to help with the development, but unfortunately a change to the business environment that I am in has meant that I don't think I will have the chance. :-( In addition, the ability to say where the added postscript code is to go would be useful. e.g. first thing in the page vs. last thing in the page. Are you talking about adding PostScript code for OMR marks or other marks to control the packaging process? Yes, identifying each page, in case the machine that careful places our perfectly rendered pages into envelopes, decides to practice modular origami. We run FOP multiple times, and in parallel, then join together all the output postscript files as desired. In doing so we insert separation pages, change page numbering based on plexing of output printed from various printers, add OMR, etc. Of use to us here would be the ability to identify resources (fonts and images) used in the documents, inserting short postscript macros to reference them during rendering, merging the lists of used resources from the parallel runs, then produce a single postscript header defining all the resources, with the names already used in the rendered documents. Obviously this is way beyond the scope of XSL-FO. FOP could possibly extend the FormattingResults to include lists of which fonts were actually used, and which images were used. I know that this could be determined by parsing the input FO, but I'm addicted to making code fast, and don't like doing things twice when once is sufficient. Something like that could be done easily. I've already improved the PostScript generation code a lot to make stuff like this easier. The only difficulty are fonts which are always a little special. I've thought about implementing a special PS generating mode which doesn't even process images, for example, but only outputs the references to an image as DSC comments. That would save a lot of file size and processing time. The images would never have to be fully loaded, only their headers analyzed, thus saving lots of memory, too. One requirement (that I am pleased to see you continuing) is the very high degree of similarity between PDF output and postscript output. Yes, that proved to be very important to many people in the past. Obviously the font handling code has a large impact here. Absolutely. A recent problem we have had is with the differing environment that Batik runs in when rendering for PDF and for postscript, specifically the identification of font resources that should be used, and why the PDF renderer starting asking for the Dialog font-family. Test cases would be welcome here to improve on that. Anyway, this is getting off topic, sorry. Not at all off-topic if you ask me. That's exactly the kind of stuff I want to hear. Jeremias Maerki
Re: Non-implemented props: border-*-precedence
[Jeremias Maerki] Perfect, Finn! I've just hacked together a little test extension that lets me evaluate properties and write failure messages to a singleton which a JUnit test case could process. It's very rough right now, but with a little more work this could really be cool for checking the FO tree. Looks very good. How about adding a property expected-outcome=success|fail (with a default of success) to test:assert, eval and true tags and when the value is fail, will either: print Expected failure still fails as expected throw Expected failure was miraculously solved!!! That way test for unimplemented features can be added without having to disable the entire test file. regards, finn
Re: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
[Manuel] Agree, and I have a solution for that ready to go. I think this deserves some further comment / discussion. One, IMO important, reason I want to do the evaluation during the FO parsing stage is that once we are in the LMs we lost the property inheritance information. That is something like: fo:block font-size=120% fo:blockText/fo:block /fo:block looks to the LM like: fo:block font-size=120% fo:block font-size=120%Text/fo:block /fo:block True, but the percentbase of the second 120% should be the same as the base of the first. They are both 120% of a value on fo:flow. So when evaluated, the result values will be the same. All inheritance must be resolve by the property system. Otherwise it is a bug. The reason for keeping the values as percentage is to support font-size=120% + 1pt and to *really* open the discussion it should be noted that the spec does *not* require additive operation on relative lengths. Only multiplications are required. Once the expression engine in fop tried to use that by calculating a factor to be applied to relative lengths. Does svn view have an attic? http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/ If it does I could propably find the code, it wasn't pretty. regards, finn
Re: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
On Tue, 30 Aug 2005 04:05 pm, Finn Bock wrote: [Manuel] Agree, and I have a solution for that ready to go. I think this deserves some further comment / discussion. One, IMO important, reason I want to do the evaluation during the FO parsing stage is that once we are in the LMs we lost the property inheritance information. That is something like: fo:block font-size=120% fo:blockText/fo:block /fo:block looks to the LM like: fo:block font-size=120% fo:block font-size=120%Text/fo:block /fo:block True, but the percentbase of the second 120% should be the same as the base of the first. Yes, but this is exactly the problem. The real percentbase, that is the actual value to use, is determined in the general case during layout. So the LM just sees 'font-size=120%' and now has to figure out the base to use. But it doesn't know that the 120% was actually inherited in the 2nd case and that it would need to backtrack to the parent to determine the base from there. They are both 120% of a value on fo:flow. So when evaluated, the result values will be the same. All inheritance must be resolve by the property system. Otherwise it is a bug. The reason for keeping the values as percentage is to support font-size=120% + 1pt and to *really* open the discussion it should be noted that the spec does *not* require additive operation on relative lengths. Only multiplications are required. I wouldn't worry about that. The current system handles it fine. Once the expression engine in fop tried to use that by calculating a factor to be applied to relative lengths. Does svn view have an attic? http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/src/java/org/ apache/fop/fo/ If it does I could propably find the code, it wasn't pretty. regards, finn Manuel
Re: page-number and page-number-citation problem
J.Pietschmann wrote: Maybe I'm wrong in trying to do so, but I'd like to handle both formatting objects in the same way. If page numbers can be resolved to strings early, it should be done. All the hassle for space readjusting, and perhaps reflowing content, should be reserved for forward references, if only for performance reasons. Sorry, my last message was not very clear (and / or I misunderstood your comments). The point is that the real page numbers are not known until the addAreas() phase, when pages are actually created. The Knuth-style page breaking algorithm gets a representation of a whole page-sequence (or part of it, if there are break conditions) and then computes all the page breaks at once: so, the fo:page-numbers comprised in that page-sequence cannot know in which page they will be placed, and the line breaking is necessarily performed using elements whose width could be just a guess. What I meant when I said that both page-number and page-number-citation should be handled in the same way was this: during the line breaking their real value is equally unknown. Well, to be more precise the value of a page-number is *always* unknown during line breaking, while a page-number-citation could refer to an object in a previous page-sequence, so it could be known: in this case the method PNCLM.get() already returns a TextArea with the real value and its ipd (maybe you were referring to this? this won't be changed at all). [from the other message] - sometimes, when a particularly elegant output is needed, it would really be desirable to have a two-steps algorithm, with line-breaking performed again once the actual width of each object is known. Well, it's not for particular elegant output, it's for the case of having multiple page number citations which point to five digit page numbers in the same line. Real life examples include references to page numbers in roman number format, which easily get into the six character range, and enumerating references in book indices, where the problem is may be amplified as an index is usually set in several narrow columns. Great examples, I did not think of them! I imagine that, should the index be in a page-sequence preceding the ones with the content, the line breaking of it could be really ugly, due to the provisional width of the references. This example is really interesting: in this case, a re-flowing of the index pages could not be able to achieve a better output, should it be performed before the breaking of the page-sequence with the content; and it could be avoided just deferring the breaking of this page-sequence, so that the first breaking can already work using the real values for all page-number-citations. If we see each page-sequence as a node, and a page-number-citation as a directed edge from one node (the target page-sequence) to another one (the page-sequence containing the page-number-citation), this is a well-known problem: the topological sorting of a graph. If the graph is acyclic then there is a sorting of its nodes such that for each edge going from a node A to a node B, A precedes B in the sorting order; i.e., the page-sequences could be ordered so that each one is flowed when all its page-number-references are already known. Very interesting indeed ... as soon as I finish working on the line-adjusting I'll spend some more thought on this ... (sorry for the long message!) Regards Luca
DO NOT REPLY [Bug 36408] - FOP hyphenation splits consecutive digits onto separate rows
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=36408. 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=36408 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-08-30 13:07 --- The correct way to stop a piece of text being split across line/page/column bounaries in XSL-Fo is to use keep-* properties. e.g. fo:inline keep-together=always12345678901234567890/fo:inline However, keep-* properties are not implemented in 0.20.5. They have been implemented in the current development version. 0.20.5 is about to be superceeded by a release of the development code and since work has stopped on the maintenance code, this bug won't be fixed in 0.20.5 and I'm closing this bug report. -- 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 36379] - [PATCH] Revised percentage resolution system
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=36379. 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=36379 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #16213|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-08-30 14:02 --- Created an attachment (id=16248) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16248action=view) Revised patch Revised, extended and better tested patch -- 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 36379] - [PATCH] Revised percentage resolution system
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=36379. 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=36379 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #16214|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-08-30 14:03 --- Created an attachment (id=16249) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16249action=view) New class to go into org.apache.fop.layoutmgr -- 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 36379] - [PATCH] Revised percentage resolution system
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=36379. 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=36379 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #16215|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-08-30 14:04 --- Created an attachment (id=16250) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16250action=view) New class for org.apache.fop.datatypes -- 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 36379] - [PATCH] Revised percentage resolution system
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=36379. 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=36379 --- Additional Comments From [EMAIL PROTECTED] 2005-08-30 14:05 --- Created an attachment (id=16251) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16251action=view) Another new class for org.apache.fop.datatypes -- 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 36379] - [PATCH] Revised percentage resolution system
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=36379. 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=36379 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #16216|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-08-30 14:05 --- Created an attachment (id=16252) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16252action=view) Testcases -- 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: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Manuel Mall wrote: PS: I can imagine Victor smiling now :-) : I told you so that not leaving all property resolution to the LM stage is going to cause trouble. Not just Victor, Manuel. But please press on re-discovering the wheel. Peter smime.p7s Description: S/MIME Cryptographic Signature
RE: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Manuel Mall wrote: PS: I can imagine Victor smiling now :-) : I told you so that not leaving all property resolution to the LM stage is going to cause trouble. Trust me, I'm not smiling. As one of our U.S. Presidents was known for saying, I feel your pain. In fact, it might be fairly said that FOray exists because I have a lower toleration for such pain than the other FOP developers. Victor Mote
Re: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
On Tue, 30 Aug 2005 08:43 pm, Victor Mote wrote: Manuel Mall wrote: PS: I can imagine Victor smiling now :-) : I told you so that not leaving all property resolution to the LM stage is going to cause trouble. Trust me, I'm not smiling. As one of our U.S. Presidents was known for saying, I feel your pain. In fact, it might be fairly said that FOray exists because I have a lower toleration for such pain than the other FOP developers. Fair enough, btw its not painful for me at all. I have joined the project with the goal to help to get FOP 1.0 out of the door in a relatively short timeframe (meaning months not years). To achieve that I am more than prepared to be pragmatic in the sense of getting things working satisfactorily than getting things perfect and at their most elegant. That doesn't mean I want to hack and slash. Good design is very important me. But there is still this goal to aim for as well and compromise may be in order at times. And isn't there still FOP 2.0 down the track for another round of serious redesign and refactoring if so desired? Hope this makes sense - especially to the active committers. Victor Mote Manuel
Re: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Manuel Mall wrote: Fair enough, btw its not painful for me at all. I have joined the project with the goal to help to get FOP 1.0 out of the door in a relatively short timeframe (meaning months not years). To achieve that I am more than prepared to be pragmatic in the sense of getting things working satisfactorily than getting things perfect and at their most elegant. That doesn't mean I want to hack and slash. Good design is very important me. But there is still this goal to aim for as well and compromise may be in order at times. This is an excellent goal. Sometimes it is all too easy to aim for 100% perfection and then FOP gets stuck - just like it has been for 2 years prior to 2005. Compromise is the key to getting 1.0 out of the door. And isn't there still FOP 2.0 down the track for another round of serious redesign and refactoring if so desired? Hope this makes sense - especially to the active committers. Perfect sense. Keep up the great contributions! Chris
DO NOT REPLY [Bug 36418] New: - [PATCH] PreviewPanel docs changed to reflect introduction of Renderable
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=36418. 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=36418 Summary: [PATCH] PreviewPanel docs changed to reflect introduction of Renderable Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: awt renderer AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] PreviewPanel docs changed to reflect introduction of Renderable and change in constructor api. -- 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: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Chris Bowditch wrote: This is an excellent goal. Sometimes it is all too easy to aim for 100% perfection and then FOP gets stuck - just like it has been for 2 years prior to 2005. Compromise is the key to getting 1.0 out of the door. This is grossly foul. I don't remember anyone striving for 100% perfection when FOP was stuck. FOP got stuck in large part because 1) it first forked itself (no pun intended), and 2) the perceived leader of the project, who was to make that strategy work, suddenly dropped completely off of the edge of the world. The *ability* to compromise and to allow for multiple solutions to the same problem was one of the driving forces behind the modularization effort. Arggh. I have no problem with you guys sailing your ship however you see fit. But I reserve the right to set the record straight when my own efforts are misrepresented. Victor Mote
DO NOT REPLY [Bug 36418] - [PATCH] PreviewPanel docs changed to reflect introduction of Renderable
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=36418. 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=36418 --- Additional Comments From [EMAIL PROTECTED] 2005-08-30 15:33 --- Created an attachment (id=16254) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16254action=view) Trival changes to class description -- 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: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Victor Mote wrote: Chris Bowditch wrote: This is an excellent goal. Sometimes it is all too easy to aim for 100% perfection and then FOP gets stuck - just like it has been for 2 years prior to 2005. Compromise is the key to getting 1.0 out of the door. This is grossly foul. I don't remember anyone striving for 100% perfection when FOP was stuck. FOP got stuck in large part because 1) it first forked itself (no pun intended), and 2) the perceived leader of the project, who was to make that strategy work, suddenly dropped completely off of the edge of the world. The *ability* to compromise and to allow for multiple solutions to the same problem was one of the driving forces behind the modularization effort. Arggh. I have no problem with you guys sailing your ship however you see fit. But I reserve the right to set the record straight when my own efforts are misrepresented. Sorry - that was not intended. I never had any opposition to what you tried to do, but I did feel some people objected to ideas because they didn't yield 100% compliance. Regardless, my main point in this thread was simply that compromise is the key to getting to a release. Which is one of your points above, right? Chris
DO NOT REPLY [Bug 36408] - FOP hyphenation splits consecutive digits onto separate rows
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=36408. 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=36408 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-08-30 16:01 --- The suggested fix wouldn't work in my case. To achieve what I want to do with the suggested fix, I'd have to write the fo:block as: fo:block hyphenation=truefo:inlineThe phone number is /fo:inlinefo:inline keep-together=always12345678901234567890/fo:inlinefo:inline./fo:inline/fo:block However, the text contents of the fo:block are dynamically generated and thus I can't decide in advance where the fo:inline nodes should go. I am reopening this bug. If the bug is invalid because of the wrong version, please reclose the bug and tell me how to report it with the corret version. -- 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: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Chris Bowditch wrote: Manuel Mall wrote: Fair enough, btw its not painful for me at all. I have joined the project with the goal to help to get FOP 1.0 out of the door in a relatively short timeframe (meaning months not years). To achieve that I am more than prepared to be pragmatic in the sense of getting things working satisfactorily than getting things perfect and at their most elegant. That doesn't mean I want to hack and slash. Good design is very important me. But there is still this goal to aim for as well and compromise may be in order at times. This is an excellent goal. Sometimes it is all too easy to aim for 100% perfection and then FOP gets stuck - just like it has been for 2 years prior to 2005. Compromise is the key to getting 1.0 out of the door. Couldn't let that one go by, Chris. These issues, which were critical to the creation of both Folio and FOray, were being thrashed out around the beginning of 2003. You've been around long enough to know that, haven't you? So for more than two years, the pragmatic Fop developers stuck their heads in the sand. The project stalled. Point the finger at those who refused to see what is now coming to the surface, and what will still have to be solved. How pragmatic. And isn't there still FOP 2.0 down the track for another round of serious redesign and refactoring if so desired? Hope this makes sense - especially to the active committers. Perfect sense. Keep up the great contributions! Perfect, in some imperfect sense of the word. Chris Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Peter B. West wrote: snip/ Couldn't let that one go by, Chris. These issues, which were critical to the creation of both Folio and FOray, were being thrashed out around the beginning of 2003. You've been around long enough to know that, haven't you? So for more than two years, the pragmatic Fop developers stuck their heads in the sand. The project stalled. Point the finger at those who refused to see what is now coming to the surface, and what will still have to be solved. How pragmatic. Yes I was around back in 2003. My apologies for offending anyone I wasn't clear enough with my offhand remarks. And yes I have buried my head in the sand as you put it. Not because I wanted to, but because my employers expect me to spend time elsewhere. I'm not going to add any more to this discussion, as I don't want to cause any further offense. Chris
Re: FOP extension to output custom PostScript instructions
On 30.08.2005 16:06:08 Finn Bock wrote: [Jeremias on fox:ps- extensions] Anybody opposed to my adding this? ... Not at all, but I assume that you ask because it can't be added as an extension that is completely seperated from FOP. That you have to make changes to FOP sources in order to add it. Yes, that's true. And that is IMO a bit of a failure of FOP and the renderer design. Why do you think this is a design failure? The problem is that XSL-FO doesn't (directly) provide for certain needs. For example, it doesn't provide any means to add device control information (like paper type and other print job information). In the past I've had to post-process PDF to add device control code. The difficult thing was to know which page was created by which simple-page-master so the right paper can be selected. Some FOP users simply need such a mechanism however it looks like. My proposal is one that doesn't try to provide a concrete means to specify paper types but simply provides a means for people to add the control code themselves. XEP and other commercial vendors did similar things, although some have chosen XML processing instructions for that. I prefer a special namespace. An alternative could probably be JDF to handle these specific features but this beast is much too complex and there are only a few expensive systems that support it. Most of us doing mass-printing simply need to inject a few PostScript commands into the PostScript stream. This should all not be very invasive. JDF: http://en.wikipedia.org/wiki/Job_Definition_Format Step 2 after this extension might be a PPD parser so the PS Renderer could create the right control code based on logical information. But that is a lot of work. I'd like to keep it simple to start with. Jeremias Maerki
DO NOT REPLY [Bug 36408] - FOP hyphenation splits consecutive digits onto separate rows
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=36408. 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=36408 --- Additional Comments From [EMAIL PROTECTED] 2005-08-30 18:05 --- I can't prove it but I'd say that FOP 0.20.5 illegally splits the long number. A number is not subject to hyphenation, is it? Anyway, FOP Trunk currently doesn't split the number but keep-together.within-line doesn't work, either. So, Joona would actually be fine with FOP Trunk except that there is no warning message, yet, when a word is rendered beyond the content rectangle (i.e. overflows the box). Other FO implementations compress the word to fit it into the content rectangle but that's probably a bad idea since it results in badly looking output. IMO this bug can be closed again, but only because Joona's problem shouldn't happen in FOP Trunk and it won't be fixed in 0.20.5. I don't have a work-around for 0.20.5, either, except to try to shut off hyphenation. Sorry. The missing keep-together.within-line feature is a different story and IMO not related to Joona's problem. -- 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: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Chris Bowditch wrote: Peter B. West wrote: snip/ Couldn't let that one go by, Chris. These issues, which were critical to the creation of both Folio and FOray, were being thrashed out around the beginning of 2003. You've been around long enough to know that, haven't you? So for more than two years, the pragmatic Fop developers stuck their heads in the sand. The project stalled. Point the finger at those who refused to see what is now coming to the surface, and what will still have to be solved. How pragmatic. Yes I was around back in 2003. My apologies for offending anyone I wasn't clear enough with my offhand remarks. And yes I have buried my head in the sand as you put it. Not because I wanted to, but because my employers expect me to spend time elsewhere. I'm not going to add any more to this discussion, as I don't want to cause any further offense. Chris No offence taken. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Let's write the release plan for the first preview release
The subject says it all: http://wiki.apache.org/xmlgraphics-fop/ReleasePlanFirstPR This is open for discussion. I'd really love to get the first release out by the end of September. Jeremias Maerki
Re: page-number and page-number-citation problem
Luca Furini wrote: The Knuth-style page breaking algorithm gets a representation of a whole page-sequence Ah, I wasn't aware of this. Well, operating on a whole page sequence makes implementing widows/orphans and other keep conditions possible without backtracking, interesting. Very interesting indeed ... as soon as I finish working on the line-adjusting I'll spend some more thought on this ... Sounds like we'll get more improvements soon... J.Pietschmann
RE: Error loading GIF image using JAI in FOP Trunk (was: Error w hile processing a PDF - OK)
Regarding a fop-users email mentioning: com/sun/media/jai/codec/FileCacheSeekableStream Reminded me of something I encountered recently: In my brief experience (of a modified version of FOP 0.20.5 that I inherited), if the href is to a file, then its input stream is being given to JAI, JAI is reading from the input stream, and writing it to another file in the temp directory, which isn't deleted, and uses up a file handle. (long running server processes don't exit, so deleteOnExit isn't very useful.) In my environment, all hrefs are to files, so I chose this alternative in org.apache.fop.image.JAIImage loadImage(): RenderedOp imageOp = JAI.create(fileload, this.m_href.getFile()); and I also added imageOp.dispose(); immediately after setting imageData. I see that trunk has rearranged things a bit, but it still appears to have the same leak. Stephen Denne
Re: svn commit: r264863 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java
[EMAIL PROTECTED] wrote: Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java URL: http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java?rev=264863r1=264862r2=264863view=diff == --- xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java (original) +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java Tue Aug 30 14:09:41 2005 @@ -24,11 +24,13 @@ // FOP import org.apache.fop.apps.FOPException; import org.apache.fop.datatypes.ColorType; +import org.apache.fop.datatypes.Length; import org.apache.fop.fo.flow.Block; import org.apache.fop.fo.pagination.Root; import org.apache.fop.fo.properties.CommonFont; import org.apache.fop.fo.properties.CommonHyphenation; import org.apache.fop.fo.properties.CommonTextDecoration; +import org.apache.fop.fo.properties.EnumLength; import org.apache.fop.fo.properties.Property; import org.apache.fop.fo.properties.SpaceProperty; @@ -83,6 +85,7 @@ private int textTransform; private Property wordSpacing; private int wrapOption; +private EnumLength baselineShift; That is wrong, EnumLength is an implementation detail which must never be used in the fo tree code. Always use Length for properties that is defined as length. // End of property values /** @@ -161,6 +164,7 @@ wordSpacing = pList.get(Constants.PR_WORD_SPACING); wrapOption = pList.get(Constants.PR_WRAP_OPTION).getEnum(); textDecoration = pList.getTextDecorationProps(); +baselineShift = (EnumLength) pList.get(Constants.PR_BASELINE_SHIFT); Don't use cast, but call the coerce methods pList.get(XXX).getLength(); I have already committed the fix for this. regards, finn
Re: svn commit: r264856 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf: TextAttributesConverter.java rtflib/rtfdoc/RtfText.java
[EMAIL PROTECTED] wrote:
+
+ private static void attrBaseLineShift(EnumLength baselineShift, RtfAttributes rtfAttr) {
+
+ String s = baselineShift.getString();
Use baselineShift.getEnum() to get the enum values that is assigned to a
length. Never ever use the getString() method, it is purely there for
debugging and for use by the testing frameworks.
I have also fixed this in SVN.
regards,
finn
Re: Error loading GIF image using JAI in FOP Trunk (was: Error w hile processing a PDF - OK)
Stephen, thanks for pointing this out (again). I'll post a patch to fix this. Manuel On Wed, 31 Aug 2005 07:02 am, Stephen Denne wrote: Regarding a fop-users email mentioning: com/sun/media/jai/codec/FileCacheSeekableStream Reminded me of something I encountered recently: In my brief experience (of a modified version of FOP 0.20.5 that I inherited), if the href is to a file, then its input stream is being given to JAI, JAI is reading from the input stream, and writing it to another file in the temp directory, which isn't deleted, and uses up a file handle. (long running server processes don't exit, so deleteOnExit isn't very useful.) In my environment, all hrefs are to files, so I chose this alternative in org.apache.fop.image.JAIImage loadImage(): RenderedOp imageOp = JAI.create(fileload, this.m_href.getFile()); and I also added imageOp.dispose(); immediately after setting imageData. I see that trunk has rearranged things a bit, but it still appears to have the same leak. Stephen Denne
DO NOT REPLY [Bug 36432] - [PATCH] JAI image does not release all resources / LinkageError not caught
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=36432. 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=36432 --- Additional Comments From [EMAIL PROTECTED] 2005-08-31 03:21 --- Created an attachment (id=16260) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16260action=view) The patch -- 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: Margins and writing mode
Just to flag that I have a patch for this. However, it depends on the big revised percentage handling patch. So I'll hang on to it for the time being. Manuel On Tue, 30 Aug 2005 02:31 pm, Jeremias Maerki wrote: margin-left always stays on the left side. The FO spec makes a clear distinction between absolute (left, top, right, bottom) and relative (start, end, before, after) properties. lr: left=start, right=end rl: left=end, right=start So you obviously hit a bug. We haven't paid so much attention to the different writing modes, yet, especially since we don't support any of the other writing modes. For me personally, the main reason is the lack of knowledge about non-latin languages. On 30.08.2005 07:02:57 Manuel Mall wrote: If I set the writing mode on a page master to rl (arabic/hebrew) and than define margin-left and right on the region body where are these margins suppose to appear on the output device, i.e. would margin-left still be on the left side of the paper and margin-right on the right side? A sample fo is further below. My problem is that on the generated PDF the margin-left is on the right and vice versa. And I am not sure if that is correct. Manuel 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=3in page-height=5in margin=18pt writing-mode=rl fo:region-body margin-top=18pt margin-bottom=12pt margin-left=15pt margin-right=36pt background-color=yellow / fo:region-before extent=18pt background-color=blue precedence=true / fo:region-after extent=12pt background-color=green precedence=true / fo:region-start extent=36pt background-color=red / fo:region-end extent=15pt background-color=orange / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true fo:static-content flow-name=xsl-region-before fo:block r e g i o n b e f o r e /fo:block /fo:static-content fo:static-content flow-name=xsl-region-after fo:block r e g i o n a f t e r /fo:block /fo:static-content fo:static-content flow-name=xsl-region-start fo:block r e g i o n s t a r t /fo:block /fo:static-content fo:static-content flow-name=xsl-region-end fo:block r e g i o n e n d /fo:block /fo:static-content fo:flow flow-name=xsl-region-body fo:block Demonstrates an 18pt margin on the page master. The page size is 5in x 3in. On the region body we have: margin-top=18pt margin-bottom=12pt margin-left=15pt margin-right=36pt. /fo:block /fo:flow /fo:page-sequence /fo:root Jeremias Maerki
Re: Percentages on region margins
On Mon, 29 Aug 2005 11:31 pm, Manuel Mall wrote: On Mon, 29 Aug 2005 11:28 pm, Jeremias Maerki wrote: On 29.08.2005 17:18:18 Manuel Mall wrote: On Mon, 29 Aug 2005 08:20 pm, Jeremias Maerki wrote: You probably missed the following: 7.10.1 margin-top says for percentages: The percentage is calculated with respect to the width of the generated box's containing block. This is true for 'margin-top' and 'margin-bottom', except in the page context, where percentages refer to page box height. Thanks for pointing this out - don't you love this spec -:). However, that's for a margin specified on a page-master. My uncertainty is with a margin specified on a region-body unless you interpret the term page context as meaning page-master and its subordinate elements in which case margins on regions would be resolved relative to the page-width/height. I agree that this may not be 100% clear but I believe this applies to the simple-page-master's immediate children, too. I mean we're outside of the normal block-level stuff and inside the page declaration. It would really be weird to base these values on anything else than the page extents. Yes I agree (with the weird bit), that's why I ask the question. So I will resolve relative to the page width/height. Further to this - what is the expectation if we change the reference orientation by 90 degrees (whichever way)? Now margin-top and bottom are along the sides and margin-before and after are across (Look at the picture in section 6.4.12 under Constraints applicable to regions of the spec if you don't quite understand what I am talking about. ). Shall we still resolve a percentage on a margin-top/bottom against the page-height? Looks awkward to me but couldn't find (that doesn't mean there is none) an answer in the spec. On 29.08.2005 13:18:59 Manuel Mall wrote: I am trying to figure out on which base value to apply the margin=5% on the fo:region-body (see fragment below): fo:simple-page-master master-name=normal page-width=5in page-height=5in margin=5% fo:region-body margin=5% / fo:region-before extent=5% / ... The margin in the page-master element is obviously based on the page-width as there is no further containing block. The percentage on the extend=5% in the fo:region-before is also relative to the page-width as the spec says so: refer to the corresponding width of the page-viewport-area. This leaves the margin on the region-body. My interpretation is that the containing block / ancestor area of the region-body is the page-reference-area. Its content rectangle would in this case have the width (5in - 2*(5in * 0.05)). If my interpretation is correct it would mean that in the above example the margins on the region-body would be smaller than the extend on the region-before (= not nice). I am concerned because it seems to be somewhat inconsistent that the percentage on extent in a region-before is evaluated against a different base than the percentage on a margin in a region-body. I would appreciate if others could cross-check if my interpretation seems ok or not. Thanks Manuel Jeremias Maerki Manuel Jeremias Maerki Manuel Manuel
Re: Let's write the release plan for the first preview release
Excellent - I like the sound of it :-). Personally, after having now used the trunk a bit and seeing the test cases, etc., I would be a bit bolder and go for a name like 1.0 alpha or 1.0EA (I think that's the terminology Sun is using for unstable early releases). The big disclaimers still apply of course. To some extend it also depends on when we want to declare a feature freeze for 1.0, aim for stability and bug removal to get to a 1.0 beta and a 1.0 release. It must be pretty close as in terms of features/compliance the trunk code already vastly exceeds 0.20.5. I would therefore like to see the release plan extended to include a rough definition of 1.0 even if it is only as a delta to what we have now, e.g. something like this (Note is only an incomplete random example!!): border-collapse=collapse = 1.0 table-layout=auto = post 1.0 fix/complete support for fo:leader = 1.0 writing-mode=rl-tb = 1.0 writing-mode=tb-rl = post 1.0 BIDI support = post 1.0 full support for font-family = 1.0 I hope that having something like this would help to focus and prioritize the work being done. Manuel On Wed, 31 Aug 2005 04:07 am, Jeremias Maerki wrote: The subject says it all: http://wiki.apache.org/xmlgraphics-fop/ReleasePlanFirstPR This is open for discussion. I'd really love to get the first release out by the end of September. Jeremias Maerki
