Bug report for Fop [2006/10/08]
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) |
| | +-+
| | | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| | | MIN=Minor NOR=Normal ENH=Enhancement |
| | | +-+
| | | | Date Posted |
| | | | +--+
| | | | | Description |
| | | | | |
| 953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t|
| 1063|New|Nor|2001-03-21|fop does not handle large fo files|
| 1180|New|Maj|2001-04-02|Problem with monospaced font |
| 1773|Opn|Blk|2001-05-16|A table that is bigger than the page produces an e|
| 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r|
| 1998|New|Nor|2001-06-05|linefeed-treatment not understood |
| 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl|
| 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row|
| 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly |
| 2909|New|Maj|2001-07-30|Gradient render error |
| 2964|Ass|Nor|2001-08-02|problems with height of cells in tables |
| 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-|
| 3044|Ass|Maj|2001-08-08|keep-together not functioning |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work |
| 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body |
| 3497|New|Cri|2001-09-07|id already exists error when using span=all attr|
| 3824|New|Blk|2001-09-25|MIF option with tables|
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts |
| 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work |
| 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D|
| 4415|New|Nor|2001-10-25|scaling=uniform does not work on images... |
| 4510|New|Nor|2001-10-30|fo:inline common properties ignored? |
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG |
| 4767|New|Nor|2001-11-09|SVG text is distored in PDF output|
| 4814|Opn|Nor|2001-11-12|0.20.2RC infinitely loops if there are tables in f|
| 5001|New|Nor|2001-11-21|content-width and content-height ignored? |
| 5010|New|Enh|2001-11-21|Better error reporting needed |
| 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using |
| 5335|New|Min|2001-12-10|Text with embedded CID fonts not retrievable from |
| 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values |
| 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop|
| 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? |
| 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output|
| 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem|
| 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render |
| 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving|
| 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label|
| 6918|New|Enh|2002-03-06|reference-orientation has no effect |
| 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi|
| 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on|
| 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in |
| 7337|New|Nor|2002-03-21|border around external image leaves empty space |
| 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page |
| 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b|
| 7525|New|Cri|2002-03-27|table with spans inside a list-block |
| 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li|
| 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images |
| 8050|New|Nor|2002-04-13|Soft hyphen (shy;) is not handled properly |
| 8321|New|Nor|2002-04-19|from-parent('width') returns 0 for nested tables |
| 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende|
|
Re: PATCH for Arabic/Persian Text, and Bidi-override!
On 08.10.2006 23:01:13 Kia Teymourian wrote: Hi all, I am working on a patch for Arabic/Persian Text decoration and Implementation of Bidi Algorithm. I have some questions about it and writing to you to ask for your assistance, could you please answer my questions! 1. Can I use java 1.5 or should preferably use 1.4 or JDK 1.3. Until further notice FOP must compile with JDK 1.3. See: http://xmlgraphics.apache.org/fop/trunk/compiling.html 2. I have a long list of constants, Unicode Arabic Presentation forms. This list will be used, when the algorithm search for the correct glyphs forms. I think for the best Performance I should define some static final arrays, and write them directly in the class program codes. They are some defined Unicode constants, which I get from the Arabic Unicode definition. It is also to put them extern in some Text files, read them from there. Which form would be the best ? Whatever is fastest. I think both approaches are fine. Have you looked at ICU4J? Maybe it already provides the functionality you need. I haven't checked. At any rate, we've considered the use of ICU4J before. 3. I should add one or two new classes, something like ArabicTextHandler.java Can I add them to the package org.apache.fop.layoutmgr ? Where is the right package? Probably org.apache.fop.layoutmgr.inline. 4. Can I use some free TTF Fonts in my test cases, they are licensed under GPL. I am going to use Persian TTF fonts from http://www.farsiweb.ir/wiki/Persian_fonts Is there any license problems? Yes, the GPL is off-limits for software distributed by the ASF. :-( See: http://www.apache.org/legal/3party.html 5. The writing-mode which is entered in a block or block-container statement has to be known by the TextLayoutManager but is not delivered correctly. TextLayoutManager.addAreas(...) is called from BlockContainerLayoutManager.getNextKnuthElements(...) and BlockManager.getNextKnuthElements(...). Why? Could you please write me your comments about the implemented writing-mode! The writing mode is communicated to child layout managers through the LayoutContext. See for example: BlockContainerLayoutManager.createLayoutContext(). Would you mind showing us a short description of your approach to implementing this? We've had people before implementing in this direction but it was often a hack and did not fit in the whole picture. I just want to spare you a late disappointment. Thanks. Some documentation will be extremely important for us, since the current team knows just about nothing about Arabic text. For example, we will not be able to determine if some output is correct or not. Jeremias Maerki
Re: Including an sRGB color profile?
Uh yeah, right. I didn't think about that. No way around subclassing Color then. On 09.10.2006 09:54:31 Peter Coppens wrote: Do you really have to extend the Color class? I think it already provides methods to access the fallback sRGB value which is actually what the FO spec wants (getRed(), getGreen(), getBlue()). Not sureall pretty new for me, but would the getRGB() functions not return the profile based converted values rather than the ones the user specified as first arguments to the rgb-icc function? Jeremias Maerki
XSL 1.1 is in Proposed Recommendation phase
Subject says it all. From the W3C news: 2006-10-06: W3C is pleased to announce the advancement of Extensible Stylesheet Language (XSL) Version 1.1 to Proposed Recommendation. Version 1.1 updates and enhances the XSL 1.0 Recommendation for change marks, indexes, multiple flows, and bookmarks, and extends support for graphics scaling, markers, and page numbers. The change list since Candidate Recommendation is available. Comments are welcome through 3 November. http://www.w3.org/TR/xsl11/ Jeremias Maerki
XSL-FO 2.0 workshop in Heidelberg next week
If anyone has any requirements for XSL-FO 2.0 which I should bring up at the workshop in Heidelberg next week, please let me know. Deadline 2006-10-16 so I have time to prepare. Luca, are you going, too? How do you travel? Jeremias Maerki
DO NOT REPLY [Bug 40695] - FO Basic link not working on line break
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=40695. 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=40695 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2006-10-09 02:22 --- Please state which version of FOP you are using: 0.20.5 or 0.92beta. -- 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 40695] - FO Basic link not working on line break
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=40695. 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=40695 [EMAIL PROTECTED] changed: What|Removed |Added Version|all |0.20.4 -- 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 40695] - FO Basic link not working on line break
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=40695. 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=40695 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2006-10-09 02:49 --- FOP 0.20.x is no longer supported. Please retest your FO on 0.92beta. Please free to re-open the bug if your FO fails with 0.92beta. -- 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 40655] - [PATCH] Failure in PNGRenderer when output file name is missing an extension
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=40655. 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=40655 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-10-09 03:34 --- Patch applied in revision 454331. Thanks. -- 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: Including an sRGB color profile?
On 09.10.2006 11:49:13 Peter Coppens wrote: What is not clear to me is how I can get hold of the color-profile information (as in fo:declarations fo:color-profile color-profile-name= src=.../ ? /fo:declarations ) Hmm, yes, I guess that will also have to be implemented. Take a look at org.apache.fop.fo.pagination.ColorProfile. Something is already there but with TODO flags. The color profiles will be stored in the Declarations object. You will then have to extend org.apache.fop.fo.pagination.Declarations with methods for accessing individual ColorProfiles. The Declarations object is accessible through the Root object. I am struggling with the fact that the Color object is created in the ColorUtil#parseColorString method which does not have access to the FO tree (I think). Indeed, ColorUtil.parseColorString() is used in various places in various contexts. For this to work as needed, every such call has to have some context information about the ICC profiles available. For example, the AreaTreeParser should equally be able to build up the color instances again from the serialized area tree. There, no FO tree is available. With the switch to use java.awt.Color you have to specify the color space when instantiating the color. I see two approaches. Either the signature of parseColorString has to change to take an extra argument that gives access to the tree or creating the java.awt.Color derived class has to be postponed. Perhaps there are other solutions as well. At first sight I would think extending parseColorString makes the most sense, but I am not sure all callers of parseColorString have access to the tree and I'd rather not see function signature changes ripple up/down further. I don't think this will go without changing some method signatures. Given that not in every context (see AreaTreeParser example above) you have the FO tree available. So it may make sense to define a ColorContext interface which allows access to the available color profiles for the document. There would be an implementation for the FO tree context and one for the AreaTreeParser context, maybe some additional implementation if necessary. But I can see that there will need to be some extensive changes. I currently don't see a way around that. But maybe someone else does. Any thoughts? Thanks! Peter PS Apologies for the 101 nature of my questions - not sure they are actually suited for this list. No, that's absolutely ok. I prefer having close contact with contributors because it minimizes the risk of late surprises for both sides. Jeremias Maerki
DO NOT REPLY [Bug 40556] - [PATCH] IndexOutOfBoundsException at ListItemLayoutManager.java:495
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=40556. 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=40556 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-10-09 03:58 --- Patch applied, in revision 454338. Thanks. -- 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 40695] - FO Basic link not working on line break
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=40695. 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=40695 [EMAIL PROTECTED] changed: What|Removed |Added Version|0.20.4 |0.92 -- 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: Including an sRGB color profile?
I don't think this will go without changing some method signatures. Given that not in every context (see AreaTreeParser example above) you have the FO tree available. So it may make sense to define a ColorContext interface which allows access to the available color profiles for the document. There would be an implementation for the FO tree context and one for the AreaTreeParser context, maybe some additional implementation if necessary. But I can see that there will need to be some extensive changes. I currently don't see a way around that. But maybe someone else does. Trying to trim down the amount of code I will have to touch (this is my first attempt to contribute to an open source project and I'd rather start as small as possible) Perhaps the following could work? (*) I add a second rgb-icc function, rgb-icc-internal or whatever that does not take an NCNAME for its colorprofile parameter, but the src of the matching element from the declarations element. (*) The user specifies rgb-icc (of course) which will always, I hope, be parsed through a call to [EMAIL PROTECTED] - ? - ColorUtil#parseColorString. The result of this is a class derived from java.awt.Color which registers rgb replacement values, icc values, color profile ncname and also the color profile src (setting the src happens in the new ICCColorFunction#eval method which has access to the fo tree) (*) If later ColorUtil#colorTOsRGBString is called, the ColorUtil returns an rgb-icc-internal iso rgb-icc call where relevant (I guess the name should be changed) (*) Obviously parsing of rgb-icc-internal will also be added, but at this stage the map is no longer needed. Thoughts on (1) this could work (2) you guys would buy into this rather awkward approach? Thanks, Peter -- View this message in context: http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6716163 Sent from the FOP - Dev mailing list archive at Nabble.com.
DO NOT REPLY [Bug 40442] - [PATCH] percent length not working in font-size for rtf output
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=40442. 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=40442 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-10-09 06:07 --- Patch applied in revision 454369. Thanks. -- 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: Including an sRGB color profile?
On second thought, having the conversion based on the profile might be the right thing to do after all. Either the renderer knows how to deal with color profiles and will do the necessary, or it does not in which case it will ask the color for its rgb values. The profile based converted values might be the best bet then. Also the xsl spec says the replacement values are used when the color profile is not available (not when the renderer does not know how to deal with it). When the profile can not be loaded, an rgb Color based on the replacement values can be created and returned. Leaves the CMYK casenot sure what to do there. I guess converting device/default cmyk to (device/default?) rgb is also easy so in that case replacement values are not needed either. That would mean that the cmyk(c,m,y,k) approach could work just as well as the perhaps more awkward rgb-icc(r,g,b,#CMYK,c,m,y,k) hack. It does seem necessary to create a CMYK color space class though (or complete the one in org.apache.fop.util). Apologies for all the confusion and unclear questions...this is (obviously) all very new for me and I am far from confident I grasp all the details or consequences of possible decisions made Jeremias Maerki-2 wrote: Uh yeah, right. I didn't think about that. No way around subclassing Color then. On 09.10.2006 09:54:31 Peter Coppens wrote: Do you really have to extend the Color class? I think it already provides methods to access the fallback sRGB value which is actually what the FO spec wants (getRed(), getGreen(), getBlue()). Not sureall pretty new for me, but would the getRGB() functions not return the profile based converted values rather than the ones the user specified as first arguments to the rgb-icc function? Jeremias Maerki -- View this message in context: http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6726105 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Including an sRGB color profile?
Hey, we're all constantly learning here and I didn't find anything confusing or unclear in your questions. From what I can read between the lines you're well on your way in the right direction. However, I must excuse myself until Wednesday before I can continue to help you since it's already very late here and I'm not available tomorrow. Maybe someone else might jump in and help in the meantime. On 09.10.2006 23:35:08 Peter Coppens wrote: On second thought, having the conversion based on the profile might be the right thing to do after all. Either the renderer knows how to deal with color profiles and will do the necessary, or it does not in which case it will ask the color for its rgb values. The profile based converted values might be the best bet then. Also the xsl spec says the replacement values are used when the color profile is not available (not when the renderer does not know how to deal with it). When the profile can not be loaded, an rgb Color based on the replacement values can be created and returned. Leaves the CMYK casenot sure what to do there. I guess converting device/default cmyk to (device/default?) rgb is also easy so in that case replacement values are not needed either. That would mean that the cmyk(c,m,y,k) approach could work just as well as the perhaps more awkward rgb-icc(r,g,b,#CMYK,c,m,y,k) hack. It does seem necessary to create a CMYK color space class though (or complete the one in org.apache.fop.util). Apologies for all the confusion and unclear questions...this is (obviously) all very new for me and I am far from confident I grasp all the details or consequences of possible decisions made Jeremias Maerki-2 wrote: Uh yeah, right. I didn't think about that. No way around subclassing Color then. On 09.10.2006 09:54:31 Peter Coppens wrote: Do you really have to extend the Color class? I think it already provides methods to access the fallback sRGB value which is actually what the FO spec wants (getRed(), getGreen(), getBlue()). Not sureall pretty new for me, but would the getRGB() functions not return the profile based converted values rather than the ones the user specified as first arguments to the rgb-icc function? Jeremias Maerki Jeremias Maerki
Re: XSL-FO 2.0 workshop in Heidelberg next week
Jeremias Maerki wrote: If anyone has any requirements for XSL-FO 2.0 which I should bring up at the workshop in Heidelberg next week, please let me know. Some rough ideas, unpolished, and without even having had a look at both 1.1 and the current 2.0 proposals: - Generalize headers/footers for every block FO, with some control of behaviour: - render at the start resp. end of each (normal) area generated by the FO - render only at page breaks, not at start of first resp. end of last area - render only at start of first resp. end of last area, not at page breaks (complement of previous behaviour) Needed for the dreaded continued next page stuff, which can then be used for lists and other blocks too. - Blocks with multicolumn layout like for body regions (difficult to implement if BPD isn't easily determined from external constraints, needs probably a memory consuming branch bound algorithm for layout). Needed for newspaper-like and journal layouts, for side boxes and such. - Text floating around areas absolutely positioned on a page. This means, among other things, that line areas may be split. In multicolumn layouts, the fixed area may affect more than one column. Needed for some journal layouts, for focus text and images, side boxes and such. - An element to get the total number of pages in a page sequence or for the whole document (instead of formatted page numbers). There are probably some generalizations in there, perhaps the number of pages which are plastered with normal areas from an arbitrary FO. Needed for some legal documents, namely contracts. - more color models - Doing something about the subtotals on this page and number of foo stuff on this page problems, preferably without plugging a complete spreadsheet language into XSLFO. Perhaps a fo:calculate refer=page/fo-id select=xpath expression/ with a possibly slightly restricted XPath expression, which selects from the referenced page. In case of subtotals, the values to be processed should probably be in FO properties (XML attrs) in a canonical lexical representation instead of using the formatted content. This avoids reparsing the formatted, possibly localized content. XSLT can easily generate the additional, redundant data. - Clarify the hyphenation-char stuff. Is it a char or a string? A FO property expression or a shorthand with a special syntax? - Fix the kludge which allows page-number-format=01 to be processed according to common expectations. If done properly, this may fix some other problems like the problem with hyphenation-char above as well. - Recommendations on metadata, references to appropriate standards - Recommendations and/or (non-)contracts on how to handle external ressources if they are used multiple times (e.g. images in static content). Useful to know how the processor may or must not behave if the ressource is dynamically generated on access. More radical thoughts: - Deprecate both list and table elements and replace by a single unified element set for grid layouts. A content flow is a series of blocks, which may contain in a blocks, inlines or a grid of other blocks. - Deprecate mixing inlines and blocks :-P - Invent controls so that blocks can be broken both in IPD and BPD for pagination. This may solve the break wide tables horizontally as well as the parallel flow text problems, unless it is already solved this way in 1.1 - Automatic page master switching in case of IPD overflow. This is the switch to landscape for wide tables/images problem. The difference to explicitely switching page masters is that some other content before/after the wide FO may flow onto the page, thereby avoiding unpleasant white areas on the page before and on the last page of the wide element. Please tell me if you need clarifications on any of the points. J.Pietschmann
Re: XSL-FO 2.0 workshop in Heidelberg next week
A few. I do think, when proposing these things, it is important to remember that XSL-FO is not intended to implement all possible typsetting operations, that it still needs to remain easily implementable. I guess one question I have is how different should XSL-FO 2.0 be from 1.1? Should it just be some minor changes/fixes, or are they considering some pretty substantial changes? Because if it is the latter, I've got some suggestions with that regard: * Eliminate entirely the notion of unbounded page lengths/viewports. That is, browser-like viewing with scrollbars and such. This, among other things, has the effect of making the viewport stuff unnecessary and substantially clarifies the specification and any descriptions thereof. The primary purpose of XSL-FO is for paged media; we already have tools for unpaged media. * Seriously reconsider having block-level elements and inline elements be interleaved. It probably makes FO processor implementation a bit more difficult. Plus, it's just needless; you can easily wrap that inline stuff in a block. * Page specification (simple-page-master) could be made so much more intuitive. It is far too easy to put a header in the middle of your content by accident, and while I support that functionality, it should not be the default. If it's just minor changes: * Allow for lists that periodically reverse the left/right (IPD, technically) positioning of the blocks. Generally, to allow for lists that alternate one after another which side the content and which side the list item is on. It would, also, be useful to alter other attributes when doing this. There is a FO-processor that has an extension to do it, but I forget its name. This alternation would likewise be reset at every page/region break. * In that same vein, similar alternation patters for table row properties that reset at page/region breaks. This would allow for alternate color backgrounds, but that always start (wherever they are visible) on a particular boundary. * FO 1.1 added the ability to have multiple body regions on a page, and a flow map to dictate how data flows from one to another. What was not added were appropriate keeps/breaks to deal with the possibility of switching to a new region without leaving the page itself. This distinction should be made. * The ability to specify 2-up/4-up/etc style page generation. This cannot be done even with FO 1.1's multiple body regions, because one lacks the ability to have multiple static content regions on a page, as well as where those regions get placed. Something like a multiple-page-master that physically shrinks several simple-page-masters onto a single page. * Footnote numbering/indexing per page or region, rather than leaving it up to the FO document. The numbering, of course, needs to be flexible and user-definable (perhaps as a sequence of character possibilities that is referenced). * Meta-data needs to be handled in some way. A section, perhaps just after the page master section, would be ideal. * Please give us a RELAX NG+Schematron schema for XSL-FO. It would be so incredibly useful to have such a thing. -- View this message in context: http://www.nabble.com/XSL-FO-2.0-workshop-in-Heidelberg-next-week-tf2408511.html#a6727041 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: PATCH for Arabic/Persian Text, and Bidi-override!
On Monday 09 October 2006 05:01, Kia Teymourian wrote: Hi all, Hi, Jeremias already responded to you and my comments go in the same direction. Firstly, its great that you want to look at this aspect. I did investigate support for UAX#14 Unicode compliant line breaking over a year ago. I recommend you search the mailing list for UAX#14 and you will find the relevant threads. Joerg contributed some code (never integrated) that implements the line breaking table lookup / state machine. That code makes use of Java classes created from Unicode data tables. You may want to have a look at that as there are possibly things you can reuse (see http://people.apache.org/~manuel/fop/linebreak.tar.gz). BTW, I would place this type of code which basically deals with text manipulation in its separate package org.apache.fop.text or org.apache.fop.text.unicode. If you look at text decorations, glyph merging, ligatures it would be good if it covers also non arabic languages. For example glyph merging applies to some european languages as well (german umlauts, french accents, etc.). Don't hesitate to ask for help on this list. I'll be happy to assist. I am working on a patch for Arabic/Persian Text decoration and Implementation of Bidi Algorithm. I have some questions about it and writing to you to ask for your assistance, could you please answer my questions! 1. Can I use java 1.5 or should preferably use 1.4 or JDK 1.3. 2. I have a long list of constants, Unicode Arabic Presentation forms. This list will be used, when the algorithm search for the correct glyphs forms. I think for the best Performance I should define some static final arrays, and write them directly in the class program codes. They are some defined Unicode constants, which I get from the Arabic Unicode definition. It is also to put them extern in some Text files, read them from there. Which form would be the best ? 3. I should add one or two new classes, something like ArabicTextHandler.java Can I add them to the package org.apache.fop.layoutmgr ? Where is the right package? 4. Can I use some free TTF Fonts in my test cases, they are licensed under GPL. I am going to use Persian TTF fonts from http://www.farsiweb.ir/wiki/Persian_fonts Is there any license problems? 5. The writing-mode which is entered in a block or block-container statement has to be known by the TextLayoutManager but is not delivered correctly. TextLayoutManager.addAreas(...) is called from BlockContainerLayoutManager.getNextKnuthElements(...) and BlockManager.getNextKnuthElements(...). Why? Could you please write me your comments about the implemented writing-mode! Thank you! best regards, Kia Teymourian Manuel
