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
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: 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
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: fo:wrapper text-decoration=underlinetext1 fo:wrapper text-decoration=overlinetext2 /fo:wrapper /fo:wrapper 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 fo:wrapper text-decoration=underlinetext1 fo:wrapper text-decoration=overline no-underlinetext2 /fo:wrapper /fo:wrapper J.Pietschmann
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
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: fo:wrapper text-decoration=underlinetext1 fo:wrapper text-decoration=overlinetext2 /fo:wrapper /fo:wrapper 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 fo:wrapper text-decoration=underlinetext1 fo:wrapper text-decoration=overline no-underlinetext2 /fo:wrapper /fo:wrapper 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
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
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
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 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|
|
