Bug report for Fop [2007/01/07]
+---+
| 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 |
| 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|fi (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 () 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|
| 8767|Ass|Min|2002-05-03|Image
compliance page - block-container
On the compliance page it indicates 'partial' for block-container in the 0.93 column but in the comments it says '[0.93] No known restrictions.'. Sounds a bit like a contradiction to me. What should it be? Manuel
Re: LineBreaking - looking for design idea
On Saturday 30 December 2006 21:50, J.Pietschmann wrote: > Manuel Mall wrote: > > Probably > > should do hyphenation at the same time as it iterates over Knuth > > elements in the LineLM and looks pretty 'ugly' as it modifies the > > Knuth elements retrospectively. > > I'm not sure this will pay off. One note in the TeX book about the > Knuth paragraph filling algorithm mentions that it called the > expensive hyphenation algorithm less often than the naive line > filling algorithm (and therefore run faster!). > Joerg, not sure this applies to fop. Seems to me, after a cursory code inspection, that we always call the hyphenation function during linebreaking (if hyphenation is enabled). Therefore doing it under the same circumstances earlier should not add any overheads. May be someone with a better understanding than me on the hyphenation subject can clarify that. > > If we do it in the whitesspace loop we would need a means of adding > > break opportunities to the data structures at this point. One > > possible solution would be to simply add a ZWSP char at each normal > > break opportunity > > I'd go for a Java break mark object, just to avoid any confusion. Yes that's clearly the cleaner solution - it just affects so many internal interfaces though. > >> and a soft hyphen char at every hyphenation point. >> This sounds *very* expensive, see above. > See above :-) > > The other idea Andreas suggested, that is to give each Inline LM > > the last and first character of the their preceeding/following LM > > when constructing the LM from the FO is also worth a look. > > Certainly, but it looks somewhat odd to modify semi-high level > APIs to cater for a much more low level algorithm. I find access > methods more attractive. > Not sure what to make of this comment. I agree in principle but have problems applying it to the situation at hand. If I knew how to easily build these access methods then I would not have started this whole discussion. > J.Pietschmann Manuel
Re: text-decoration inheritance
On Sunday 07 January 2007 23:04, J.Pietschmann wrote: > Manuel Mall wrote: > > I was just looking at some inline handling stuff and came across > > the inheritance behaviour of the text-decoration property. > > IIRC one of the problems is merging the various decoration values: > text1 >text2 > > > I'd say "text 2" should be both underlined and overlined. I > text-decoration were inherited, the decoration of the inner > wrapper would already override underlining. > In order to turn off underlining, one should use > text1 >text2 > > > Joerg, that makes sense to me. It seems the spec is once again confusingly worded. What you are saying is that the intention of the spec is to treat the text-decoration property actually as 4 separate inheritable properties like: text-decoration-underline: Value: false | true | inherit Initial: false Inherited: yes text-decoration-overline: ... text-decoration-line-through: ... text-decoration-blink: ... Actually as color is inherited as well the properties are more like: text-decoration-underline-style: Value: none | solid | inherit Initial: none Inherited: yes text-decoration-underline-color: Value: auto Initial: auto Inherited: yes With the prose then explaining that auto means the font color of the element the corresponding text-decoration-...-style property is explicit set on. The current text-decoration property then just becomes a shorthand for the above. If this interpretation of the spec intention is correct then FOP behaves OK. > J.Pietschmann Manuel
FOP Bridge for FOP 0.93
Hello FOP and Eclipse Users, I have updated the FOP Bridge plugin for Eclipse to support FOP 0.93. For those who are not familiar, the plugin allows you to transform XSL FO documents from within eclipse with a simple right-click. You can download it from http://www.ahmadsoft.org/fopbridge.html or you can use the update site located at http://www.ahmadsoft.org/update/. Thank you, Amin
Re: text-decoration inheritance
Manuel Mall wrote: I was just looking at some inline handling stuff and came across the inheritance behaviour of the text-decoration property. IIRC one of the problems is merging the various decoration values: text1 text2 I'd say "text 2" should be both underlined and overlined. I text-decoration were inherited, the decoration of the inner wrapper would already override underlining. In order to turn off underlining, one should use text1 text2 J.Pietschmann
Re: Add bugzilla entry for the new release id.
Simon Pepping schrieb: Add bugzilla entry for the new release id: How do I do that? Ask someone who has admin rights for bugzilla ;-) (I think I'm the only one within the XML Graphics Project, another way would be to create an issue at https://issues.apache.org/jira/browse/INFRA) I've added version 0.93. Christian
Add bugzilla entry for the new release id.
Add bugzilla entry for the new release id: How do I do that? -- Simon Pepping home page: http://www.leverkruid.eu
Re: [VOTE] Release of FOP 0.93
On Wed, Jan 03, 2007 at 11:25:05PM +0100, Simon Pepping wrote: > I have again prepared the release files for the FOP 0.93 release. They > were created from the tag > https://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-0_93. You > can find them at http://people.apache.org/~spepping/. They are signed 8 committers have voted. All votes are positive, although there were some reservations about some imperfections. Of the PMC, 6 out of 8 members have voted. Therefore the release has been accepted. I will move the above files to the distribution directory (http://www.apache.org/dist/xmlgraphics/fop/), wait 24 hrs for the mirrors to catch up, and then announce the release. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: text-decoration inheritance
On Jan 7, 2007, at 10:34, Manuel Mall wrote: Hi Manuel, 1) ...some text red text more text ... Should 'red text' be underlined or not? We currently do underline the text but I interpret the spec that we should not. Only text-decoration applied to a block level element propagates to nested inlines. text-decoration applied to an inline does not propagate. Going back to the original, I read the following: "This property describes decorations that are added to the text of an element. If the property is specified for a block-level element, it affects all inline-level descendants of the element. If it is specified for (or affects) an inline-level element, it affects all boxes generated by the element." and "This property is not inherited, but descendant boxes of a block box should be formatted with the same decoration." Being specified on the outer fo:inline, the question becomes: Are the boxes generated by the inner fo:inline to be considered as also being generated by the outer fo:inline? If yes, then FOP behaves the right way. If 'all boxes generated by the element' refers only to the boxes that correspond to the element's text child-nodes (not counting descendant elements), then this needs to be corrected. 2) ...some text red text more text ... Same question: Should 'red text' be underlined or not? We currently do underline the text but I interpret the spec that we should not. text-decoration applied to a block level element propagates to nested inlines only not to nested blocks. Analogous question here WRT to the text-node that is a descendant of the inner fo:block, although this seems clearer: a) 'descendant boxes of a block box should be formatted with the same decoration' b) 'descendant' is not the same as 'child' This would lead me to conclude that the box containing the text 'red text' counts as a descendant box of the outer block, and thus should receive the same text-decoration. Any other thoughts? Cheers, Andreas
text-decoration inheritance
I was just looking at some inline handling stuff and came across the inheritance behaviour of the text-decoration property. text-decoration is not an inherited property but has some 'inheritance' like behaviour (see spec (1.1) section 7.17.4 (7.16.4 if using 1.0 spec)). I am now wondering if we do this right: 1) ...some text red text more text ... Should 'red text' be underlined or not? We currently do underline the text but I interpret the spec that we should not. Only text-decoration applied to a block level element propagates to nested inlines. text-decoration applied to an inline does not propagate. 2) ...some text red text more text ... Same question: Should 'red text' be underlined or not? We currently do underline the text but I interpret the spec that we should not. text-decoration applied to a block level element propagates to nested inlines only not to nested blocks. Most likely I am misreading the spec but I am still curious how others interpret this aspect. Manuel
