cvs commit: xml-fop/docs/design/alt.design block-stacking-constraints.fig block-stacking-constraints.png block-stacking-keeps.fig block-stacking-keeps.png block-stacking.fig block-stacking.png
pbwest 02/04/28 01:07:18 Added: docs/design/alt.design block-stacking-constraints.fig block-stacking-constraints.png block-stacking-keeps.fig block-stacking-keeps.png block-stacking.fig block-stacking.png Log: Image files for ALT DESIGN spaces and keeps documents Revision ChangesPath 1.1 xml-fop/docs/design/alt.design/block-stacking-constraints.fig Index: block-stacking-constraints.fig === #FIG 3.2 Landscape Center Inches Letter 100.00 Single -2 1200 2 6 300 4575 1350 6300 2 2 0 2 0 7 70 0 20 0.000 0 0 -1 0 0 5 375 4650 1275 4650 1275 4875 375 4875 375 4650 2 2 0 2 0 27 80 0 20 0.000 0 0 -1 0 0 5 375 5100 1275 5100 1275 5325 375 5325 375 5100 2 2 0 2 0 11 90 0 20 0.000 0 0 -1 0 0 5 375 5550 1275 5550 1275 5775 375 5775 375 5550 2 2 0 2 0 14 100 0 20 0.000 0 0 -1 0 0 5 375 6000 1275 6000 1275 6225 375 6225 375 6000 -6 6 7575 2325 10425 5100 2 2 0 2 0 14 100 0 20 0.000 0 0 -1 0 0 5 7650 2400 10350 2400 10350 5025 7650 5025 7650 2400 2 2 0 2 0 7 60 0 20 0.000 0 0 -1 0 0 5 8175 2925 9825 2925 9825 3600 8175 3600 8175 2925 2 2 0 2 0 14 70 0 20 0.000 0 0 -1 0 0 5 8025 2775 9975 2775 9975 3750 8025 3750 8025 2775 2 2 0 2 0 7 80 0 20 0.000 0 0 -1 0 0 5 7950 2700 10050 2700 10050 4725 7950 4725 7950 2700 4 0 0 50 0 2 18 0. 4 195 165 8850 4350 P\001 4 0 0 50 0 2 18 0. 4 195 180 8850 3300 B\001 -6 6 6975 5400 10725 6225 2 1 0 4 0 7 50 0 -1 0.000 0 0 -1 0 0 2 7050 6150 8175 6150 2 2 0 6 19 7 55 0 -1 0.000 0 0 -1 0 0 5 7125 5475 8175 5475 8175 5700 7125 5700 7125 5475 4 0 0 50 0 0 16 0. 4 165 1470 8400 6225 Fence before P\001 4 0 0 50 0 0 16 0. 4 225 2265 8400 5700 Stacking constraint A,B\001 -6 6 2850 5400 6450 6300 2 2 0 4 4 7 50 0 -1 0.000 0 0 -1 0 0 5 2925 5475 3975 5475 3975 5700 2925 5700 2925 5475 2 2 0 4 5 7 50 0 -1 0.000 0 0 -1 0 0 5 2925 6000 3975 6000 3975 6225 2925 6225 2925 6000 4 0 0 50 0 0 16 0. 4 225 2220 4200 6225 Stacking constraint P,B\001 4 0 0 50 0 0 16 0. 4 225 2250 4200 5700 Stacking constraint A,P\001 -6 2 2 0 2 0 7 70 0 20 0.000 0 0 -1 0 0 5 1125 1275 2625 1275 2625 1950 1125 1950 1125 1275 2 2 0 2 0 27 80 0 20 0.000 0 0 -1 0 0 5 900 1050 2850 1050 2850 2175 900 2175 900 1050 2 2 0 2 0 11 90 0 20 0.000 0 0 -1 0 0 5 750 900 3000 900 3000 2325 750 2325 750 900 2 2 0 2 0 14 100 0 20 0.000 0 0 -1 0 0 5 525 675 3225 675 3225 2550 525 2550 525 675 2 2 0 2 0 7 70 0 20 0.000 0 0 -1 0 0 5 4200 825 6600 825 6600 2175 4200 2175 4200 825 2 2 0 2 0 14 100 0 20 0.000 0 0 -1 0 0 5 4050 675 6750 675 6750 2325 4050 2325 4050 675 2 2 0 2 0 7 70 0 20 0.000 0 0 -1 0 0 5 7800 825 10200 825 10200 2175 7800 2175 7800 825 2 2 0 2 0 14 100 0 20 0.000 0 0 -1 0 0 5 7650 675 10350 675 10350 2325 7650 2325 7650 675 2 2 0 4 4 7 50 0 -1 0.000 0 0 -1 0 0 5 375 2325 3375 2325 3375 2775 375 2775 375 2325 2 2 0 2 0 7 70 0 20 0.000 0 0 -1 0 0 5 675 2775 3075 2775 3075 4125 675 4125 675 2775 2 2 0 2 0 14 100 0 20 0.000 0 0 -1 0 0 5 525 2625 3225 2625 3225 4275 525 4275 525 2625 2 2 0 4 5 7 50 0 -1 0.000 0 0 -1 0 0 5 3900 2775 6900 2775 6900 2925 3900 2925 3900 2775 2 1 0 4 0 7 50 0 -1 0.000 0 0 -1 0 0 2 3825 2700 6975 2700 2 2 0 4 4 7 50 0 -1 0.000 0 0 -1 0 0 5 3900 2175 6900 2175 6900 2550 3900 2550 3900 2175 2 2 0 2 0 14 100 0 20 0.000 0 0 -1 0 0 5 4050 2400 6750 2400 6750 5025 4050 5025 4050 2400 2 2 0 2 0 7 60 0 20 0.000 0 0 -1 0 0 5 4575 2925 6225 2925 6225 3600 4575 3600 4575 2925 2 2 0 2 0 14 70 0 20 0.000 0 0 -1 0 0 5 4425 2775 6375 2775 6375 3750 4425 3750 4425 2775 2 2 0 2 0 7 80 0 20 0.000 0 0 -1 0 0 5 4350 2700 6450 2700 6450 4725 4350 4725 4350 2700 2 2 0 2 0 27 90 0 20 0.000 0 0 -1 0 0 5 4200 2550 6600 2550 6600 4875 4200 4875 4200 2550 2 2 0 6 19 7 55 0 -1 0.000 0 0 -1 0 0 5 7350 2175 10650 2175 10650 2925 7350 2925 7350 2175 2 2 0 4 5 7 50 0 -1 0.000 0 0 -1 0 0 5 7500 2775 10500 2775 10500 2925 7500 2925 7500 2775 2 2 0 4 4 7 50 0 -1 0.000 0 0 -1 0 0 5 7500 2175 10500 2175 10500 2700 7500 2700 7500 2175 4 0 0 50 0 0 18 0. 4 255 225 525 375 a)\001 4 0 0 50 0 0 18 0. 4 255 240 4050 375 b)\001 4 0 0 50 0 0 18 0. 4 255 225 7650 375 c)\001 4 0 0 50 0 0 16 0. 4 225 1725 1425 4875 Content rectangle\001 4 0 0 50 0 0 16 0. 4 165 690 1425 5325 Border\001 4 0 0 50 0 0 16 0. 4 225 720 1425 6225 Spaces\001 4 0 0 50 0 0 16 0. 4 225 780 1425 5775 Padding\001 4 0 0 50 0 2 18 0. 4 195 195 1725 1725 A\001 4 0 0 50 0 2 18 0. 4 195 195 5250 1575 A\001 4
cvs commit: xml-fop/docs/design/alt.design initial-column-values.dia
pbwest 02/04/28 01:12:09 Added: docs/design/alt.design initial-column-values.dia Log: Editable version of corresponding png Revision ChangesPath 1.1 xml-fop/docs/design/alt.design/initial-column-values.dia Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/design/alt.design coroutines.dia
pbwest 02/04/28 01:15:10 Added: docs/design/alt.design coroutines.dia Log: Dia editable version of png Revision ChangesPath 1.1 xml-fop/docs/design/alt.design/coroutines.dia Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/design/alt.design line-area-5.dia line-area-6.dia
pbwest 02/04/28 01:17:40 Added: docs/design/alt.design line-area-5.dia line-area-6.dia Log: Dia editable version of png Revision ChangesPath 1.1 xml-fop/docs/design/alt.design/line-area-5.dia Binary file 1.1 xml-fop/docs/design/alt.design/line-area-6.dia Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/design/alt.design dirlist.html
pbwest 02/04/28 05:54:07 Removed: docs/design/alt.design dirlist.html Log: Unnecessary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/design/alt.design traits.xml
pbwest 02/04/28 06:14:45 Modified:docs/design/alt.design traits.xml Log: Format of multiple entries tidied up. Revision ChangesPath 1.3 +43 -118 xml-fop/docs/design/alt.design/traits.xml Index: traits.xml === RCS file: /home/cvs/xml-fop/docs/design/alt.design/traits.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- traits.xml28 Mar 2002 06:58:13 - 1.2 +++ traits.xml28 Apr 2002 13:14:45 - 1.3 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=ISO-8859-1? -!-- $Id: traits.xml,v 1.2 2002/03/28 06:58:13 keiron Exp $ -- +!-- $Id: traits.xml,v 1.3 2002/04/28 13:14:45 pbwest Exp $ -- !-- !DOCTYPE document SYSTEM ../../xml-docs/dtd/document-v10.dtd -- @@ -29,7 +29,10 @@ td link href= http://www.w3.org/TR/xsl/slice4.html#area-common; -4.2.2 Common Traits/link + 4.2.2 Common Traits/linkbr/ +link href= +http://www.w3.org/TR/xsl/slice7.html#writing-mode; +7.27.7 writing-mode/link /td td link href= @@ -38,20 +41,15 @@ /td /tr tr - th colspan=2/ - td -link href= -http://www.w3.org/TR/xsl/slice7.html#writing-mode; -7.27.7 writing-mode/link - /td -/tr -tr tdinline-progression-direction/td tdAll areas/td td link href= http://www.w3.org/TR/xsl/slice4.html#area-common; -4.2.2 Common Traits/link +4.2.2 Common Traits/linkbr/ +link href= +http://www.w3.org/TR/xsl/slice7.html#writing-mode; +7.27.7 writing-mode/link /td td link href= @@ -60,14 +58,6 @@ /td /tr tr - th colspan=2/ - td -link href= -http://www.w3.org/TR/xsl/slice7.html#writing-mode; -7.27.7 writing-mode/link - /td -/tr -tr tdshift-direction/td tdInline areas/td /tr @@ -77,69 +67,38 @@ td link href= http://www.w3.org/TR/xsl/slice4.html#area-common; -4.2.2 Common Traits/link - /td - td -link href= -http://www.w3.org/TR/xsl/slice7.html#glyph-orientation-horizontal; -7.27.2 glyph-orientation-horizontal/link - /td -/tr - tr - th colspan=2/ - td +4.2.2 Common Traits/linkbr/ link href= http://www.w3.org/TR/xsl/slice4.html#area-glyph; -4.6.2 Glyph-areas/link - /td - td -link href= -http://www.w3.org/TR/xsl/slice7.html#glyph-orientation-vertical; -7.27.3 glyph-orientation-vertical/link - /td - /tr - tr - th colspan=2/ - td +4.6.2 Glyph-areas/linkbr/ link href= http://www.w3.org/TR/xsl/slice4.html#area-linebuild; -4.7.2 Line-building/link - /td - td -link href= -http://www.w3.org/TR/xsl/slice7.html#direction; -7.27.1 direction/link - /td - /tr - tr - th colspan=2/ - td +4.7.2 Line-building/linkbr/ link href= http://www.w3.org/TR/xsl/slice4.html#rend-intrinsic; -4.9.5 Intrinsic Marks/link - /td - td -link href= -http://www.w3.org/TR/xsl/slice7.html#writing-mode; -7.27.7 writing-mode/link - /td - /tr - tr - th colspan=2/ - td +4.9.5 Intrinsic Marks/linkbr/ link href= http://www.w3.org/TR/xsl/slice7.html#font-model; -7.8.1 Fonts and Font Data/link - /td - /tr - tr - th colspan=2/ - td +7.8.1 Fonts and Font Data/linkbr/ link href= http://www.w3.org/TR/xsl/slice7.html#writing-mode-related; 7.27 Writing-mode-related Properties/link /td - /tr + td +link href= +http://www.w3.org/TR/xsl/slice7.html#glyph-orientation-horizontal; +7.27.2 glyph-orientation-horizontal/linkbr/ +link href= +http://www.w3.org/TR/xsl/slice7.html#glyph-orientation-vertical; +7.27.3 glyph-orientation-vertical/linkbr/ + link href= +
cvs commit: xml-fop/docs/design/alt.design keeps.xml spaces.xml
pbwest 02/04/28 06:27:44 Added: docs/design/alt.design keeps.xml spaces.xml Log: Adding documents to ALT DESIGN Revision ChangesPath 1.1 xml-fop/docs/design/alt.design/keeps.xml Index: keeps.xml === ?xml version=1.0 encoding=ISO-8859-1? !-- $Id: keeps.xml,v 1.1 2002/04/28 13:27:44 pbwest Exp $ -- !-- !DOCTYPE document SYSTEM ../../xml-docs/dtd/document-v10.dtd -- document header titleKeeps and breaks/title authors person name=Peter B. West email=[EMAIL PROTECTED]/ /authors /header body !-- one of (anchor s1) -- s1 title=Keeps and breaks in layout galleys p The link href= galleys.html layout galleys/link and the link href= galleys.html#layout-tree layout tree/link which is their context have been discussed elsewhere. Here we discuss a possible method of implementing keeps and breaks within the context of layout galleys and the layout tree. /p s2 title=Breaks p Breaks may be handled by inserting a column- or page-break pseudo-object into the galley stream. For break-before, the object would be inserted before the area in which the flow object, to which the property is attached, is leading. If the flow object is leading in no ancestor context, the pseudo-object is inserted before the object itself. Corresponding considerations apply for break-after. Selection of the position for these objects will be further examined in the discussion on keeps. /p /s2 s2 title=Keeps p Conceptually, all keeps can be represented by a keep-together pseudo-area. The keep-together property itself is expressed during layout by wrapping all of the generated areas in a keep-together area. Keep-with-previous on formatting object A becomes a keep-together area spanning the first non-blank normal area leaf node, L, generated by A or its offspring, and the last non-blank normal area leaf node preceding L in the area tree. Likewise, keep-with-next on formatting object A becomes a keep-together area spanning the last non-blank normal area leaf node, L, generated by A or its offspring, and the first non-blank normal area leaf node following L in the area tree. br/TODO REWORK THIS for block vs inline /p p The obvious problem with this arrangement is that the keep-together area violate the hierarachical arrangement of the layout tree. They form a concurrent structure focussed on the leaf nodes. This seems to be the essential problem of handling keep-with-(previous/next); that it cuts across the otherwise tree-structured flow of processing. Such problems are endemic in page layout. /p p In any case, it seems that the relationships between areas that are of interest in keep processing need some form of direct expression, parallel to the layout tree itself. Restricting ourselves too block-level elements, and looking only at the simple block stacking cases, we get a diagram like the attached PNG. In order to track the relationships through the tree, we need four sets of links. /p p strongFigure 1/strong /p anchor id=Figure1/ figure src=block-stacking.png alt=Simple block-stacking diagram/ p The three basic links are: /p ul !-- one of (dl sl ul ol li) -- liLeading edge to leading edge of first normal child./li liTrailing edge to leading edge of next normal sibling./li liTrailing edge to trailing edge of parent./li /ul p Superimposed on the basic links are bridging links which span adjacent sets of links. These spanning links are the tree violators, and give direct access to the areas which are of interest in keep processing. They could be implemented as double-linked lists, either within the layout tree nodes or as separate structures. Gaps in the spanning links are joined by simply reproducing the single links, as in the diagram. The whole layout tree for a page is effectively threaded in order of interest, as far as keeps are concerned. /p p The bonus of this structure is that it looks like a superset of the stacking constraints. It gives direct access to all sets of adjacent edges and sets of edges whose space specifiers need to be resolved.
cvs commit: xml-fop/docs/design/alt.design book.xml
pbwest 02/04/28 06:54:40 Modified:docs/design/alt.design book.xml Log: Added keeps and spaces Revision ChangesPath 1.3 +2 -0 xml-fop/docs/design/alt.design/book.xml Index: book.xml === RCS file: /home/cvs/xml-fop/docs/design/alt.design/book.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- book.xml 27 Mar 2002 07:59:56 - 1.2 +++ book.xml 28 Apr 2002 13:54:40 - 1.3 @@ -8,6 +8,8 @@ page id=index label=co-routines source=coroutines.xml/ page id=galleys label=galleys source=galleys.xml/ page id=footnotes label=footnotes source=footnotes.xml/ + page id=keeps label=keeps source=keeps.xml/ + page id=spaces label=space-specifiers source=spaces.xml/ separator/ page id=alt.properties label=alt.properties source=alt.properties.xml/ page id=classes-overview label=Classes overview source=classes-overview.xml/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug report for Fop [2002/04/28]
+---+ | 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 | | | | | | | | 626|New|Nor|2001-02-16|Negative number are shifted slightly towards left.| | 664|Opn|Nor|2001-02-21|Basic-Link does not move with its content, when us| | 682|New|Nor|2001-02-22|Lists do not display correctly| | 684|New|Nor|2001-02-23|border width in tables adds up| | 836|New|Min|2001-03-05|hyphenation problem with very long words | | 839|New|Nor|2001-03-05|Positioning of blocks in a block section. | | 902|New|Nor|2001-03-08|line-height is not applied corectly when using the| | 907|New|Nor|2001-03-08|first list-item dropped at very bottom of page. | | 928|New|Nor|2001-03-10|Font metrics and setComponent | | 964|New|Nor|2001-03-13|FOP 0.17 throws exception with basic-link in xsl-r| | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 1130|New|Nor|2001-03-27|Alignment of page-number-citation inside a ToC| | 1154|New|Nor|2001-03-29|nested lists more than 3 level depth | | 1171|New|Nor|2001-03-30|small-caps in static content becomes all-caps | | 1180|New|Maj|2001-04-02|Problem with monospaced font | | 1211|New|Min|2001-04-04|Tables are not formatted properly.| | 1231|New|Nor|2001-04-05|basic-link can't link to a page-sequence element | | 1242|New|Nor|2001-04-06|Error in Font-Documentation | | 1261|New|Nor|2001-04-09|problem with rendering of external-graphic in Fop-| | 1318|New|Nor|2001-04-12|problems with tables (column width and when used i| | 1332|Ass|Nor|2001-04-12|MIF output strings not properly escaped | | 1391|New|Blk|2001-04-19|Bug in border-top-style | | 1474|New|Maj|2001-04-24|fo:external-graphic rendered as block level object| | 1531|New|Cri|2001-04-26|Cell Spacing | | 1724|Opn|Nor|2001-05-11|Text alignment in table cells | | 1759|New|Nor|2001-05-15|table-omit-footer-at-break sometimes cause crash | | 1766|New|Maj|2001-05-15|Text matrix in svg get doubled when run thru FOP | | 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r| | 1923|New|Nor|2001-05-28|text-decoration does not work | | 1952|New|Cri|2001-06-01|color attribute to table content overflowing on ne| | 1967|New|Nor|2001-06-02|blank-or-not-blank behavior | | 1998|New|Nor|2001-06-05|linefeed-treatment not understood | | 2106|New|Nor|2001-06-11|broken justification with numeric umlaut entities | | 2107|New|Min|2001-06-11|indentation in em units is larger than the lette| | 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl| | 2153|New|Cri|2001-06-13|Borders are calculated incorrectly| | 2207|New|Maj|2001-06-18|Embedding problems| | 2279|New|Nor|2001-06-22|block-container property position does not exist| | 2460|New|Cri|2001-07-05|Mulitple boder lines between the colums in a table| | 2463|New|Nor|2001-07-05|No of lines per page in a PDF output file | | 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row| | 2491|New|Cri|2001-07-06|footnote can't fit remaining space and crash | | 2504|New|Nor|2001-07-08|Some font properties in tables are not preserved a| | 2532|New|Cri|2001-07-10|FOP 0.17 does not work with WebSphere V3.5 OS/390 | | 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly | | 2867|New|Nor|2001-07-27|external-graphic content-width and content-height | | 2880|New|Maj|2001-07-30|Incorrect rendering on non-ASCII machines | | 2909|New|Maj|2001-07-30|Gradient render error | | 2964|New|Nor|2001-08-02|problems with height of cells in tables | | 2987|New|Nor|2001-08-03|Large graphics put FOP 0.19 into an infinite loop | | 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-| |
Re: Interesting Aside
Rhett Aultman wrote: Hear hear! XSLT and XSL-FO have been, in my line of work, the killer apps of XML. Exactly. Half a year ago I started to use XML+XSLT+FOP for a variety of formal letters, after I found it too hard to get Word auotmated for simple tasks. Surprisingly, I'm faster to type XML (using Emacs+PSGML) then to fiddle with the various Word positioning and paper format stuff (there's *always* something wrong). Paper and envelope measurements (unscrupolously lifted from http://www.cl.cam.ac.uk/~mgk25/iso-paper.html) are stored in a separate XML file, together with folding marks, address placement boxes and sensible margin settings, and are selected via an XSLT parameter. Now i can concentrate on content rather than guessing where Word thinks it should put addresses, subjects and headers. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/traits - New directory
klease 02/04/28 14:20:13 xml-fop/src/org/apache/fop/traits - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Insufficient Karma!
Peter B. West wrote: Access denied: Insufficient Karma This seems to be a recurrent problem. I thought you've read the maling list.. bg http://marc.theaimsgroup.com/?l=fop-devm=97915458410778w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/traits BlockProps.java InlineProps.java LayoutProps.java SpaceVal.java
klease 02/04/28 14:28:02
Modified:src/codegen foproperties.xml
src/org/apache/fop/area BodyRegion.java MinOptMax.java
src/org/apache/fop/datatypes Space.java
src/org/apache/fop/fo FOText.java FObj.java FObjMixed.java
PropertyManager.java TextInfo.java
src/org/apache/fop/fo/flow Block.java
src/org/apache/fop/layout MarginInlineProps.java
src/org/apache/fop/layoutmgr BlockLayoutManager.java
BlockStackingLayoutManager.java
LineLayoutManager.java SpaceSpecifier.java
Added: src/org/apache/fop/traits BlockProps.java InlineProps.java
LayoutProps.java SpaceVal.java
Log:
Add BreakPossibility style LayoutManager code as an alternative to
Keiron's direct area creation method. Not currently enabled: to do
so, one must make 2 changes in the source.
Revision ChangesPath
1.31 +5 -2 xml-fop/src/codegen/foproperties.xml
Index: foproperties.xml
===
RCS file: /home/cvs/xml-fop/src/codegen/foproperties.xml,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- foproperties.xml 23 Feb 2002 16:47:01 - 1.30
+++ foproperties.xml 28 Apr 2002 21:28:01 - 1.31
@@ -1282,8 +1282,11 @@
property
nameword-spacing/name
inheritedtrue/inherited
-datatypeToBeImplemented/datatype
-defaultnormal/default
+use-genericGenericSpace/use-generic
+default subproperty=precedenceforce/default
+default subproperty=conditionalitydiscard/default
+default0pt/default
+!-- defaultnormal/default --
/property
!-- Color-related Properties --
1.5 +6 -1 xml-fop/src/org/apache/fop/area/BodyRegion.java
Index: BodyRegion.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/BodyRegion.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- BodyRegion.java 17 Feb 2002 21:59:29 - 1.4
+++ BodyRegion.java 28 Apr 2002 21:28:01 - 1.5
@@ -1,5 +1,5 @@
/*
- * $Id: BodyRegion.java,v 1.4 2002/02/17 21:59:29 klease Exp $
+ * $Id: BodyRegion.java,v 1.5 2002/04/28 21:28:01 klease Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -29,6 +29,11 @@
// Number of columns when not spanning
public void setColumnCount(int colCount) {
this.columnCount = colCount;
+}
+
+// Number of columns when not spanning
+public int getColumnCount() {
+ return this.columnCount ;
}
// A length (mpoints)
1.3 +17 -2 xml-fop/src/org/apache/fop/area/MinOptMax.java
Index: MinOptMax.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/MinOptMax.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MinOptMax.java11 Nov 2001 14:10:29 - 1.2
+++ MinOptMax.java28 Apr 2002 21:28:01 - 1.3
@@ -1,5 +1,5 @@
/*
- * $Id: MinOptMax.java,v 1.2 2001/11/11 14:10:29 klease Exp $
+ * $Id: MinOptMax.java,v 1.3 2002/04/28 21:28:01 klease Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -14,7 +14,7 @@
* variables are package visible.
*/
-public class MinOptMax implements java.io.Serializable {
+public class MinOptMax implements java.io.Serializable, Cloneable {
/** Publicly visible min(imum), opt(imum) and max(imum) values.*/
public int min;
@@ -35,6 +35,15 @@
this.max = max;
}
+public Object clone() {
+ try {
+ return super.clone();
+ } catch (CloneNotSupportedException ex) {
+ // SHOULD NEVER OCCUR - all members are primitive types!
+ return null;
+ }
+}
+
public static MinOptMax subtract(MinOptMax op1, MinOptMax op2) {
return new MinOptMax(op1.min - op2.max, op1.opt - op2.opt,
op1.max - op2.min);
@@ -43,6 +52,12 @@
public static MinOptMax add(MinOptMax op1, MinOptMax op2) {
return new MinOptMax(op1.min + op2.min, op1.opt + op2.opt,
op1.max + op2.max);
+}
+
+public static MinOptMax multiply(MinOptMax op1, double mult) {
+ return new MinOptMax((int)(op1.min * mult),
+ (int)(op1.opt * mult),
+ (int)(op1.max * mult));
}
cvs commit: xml-fop/src/org/apache/fop/layoutmgr AbstractBPLayoutManager.java BPLayoutManager.java BreakPoss.java BreakPossPosIter.java LayoutContext.java LineBPLayoutManager.java PositionIterator.java TextBPLayoutManager.java
klease 02/04/28 14:31:00
Added: src/org/apache/fop/layoutmgr AbstractBPLayoutManager.java
BPLayoutManager.java BreakPoss.java
BreakPossPosIter.java LayoutContext.java
LineBPLayoutManager.java PositionIterator.java
TextBPLayoutManager.java
Log:
New files for the BreakPoss(ibility) Layout Manager scheme
Revision ChangesPath
1.1
xml-fop/src/org/apache/fop/layoutmgr/AbstractBPLayoutManager.java
Index: AbstractBPLayoutManager.java
===
/*
* $Id: AbstractBPLayoutManager.java,v 1.1 2002/04/28 21:31:00 klease Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
*/
package org.apache.fop.layoutmgr;
import org.apache.fop.fo.FObj;
import org.apache.fop.fo.PropertyManager;
import org.apache.fop.fo.FONode;
import org.apache.fop.area.Area;
import java.util.ListIterator;
import java.util.ArrayList;
/**
* The base class for all BPLayoutManagers.
*/
public abstract class AbstractBPLayoutManager extends AbstractLayoutManager
implements BPLayoutManager {
/** True if this LayoutManager has handled all of its content. */
private boolean m_bFinished = false;
public AbstractBPLayoutManager(FObj fobj) {
super(fobj);
}
/**
* This method provides a hook for a LayoutManager to intialize traits
* for the areas it will create, based on Properties set on its FO.
*/
protected final void initProperties() {
if (fobj != null) {
initProperties(fobj.getPropertyManager());
}
}
/**
* This method provides a hook for a LayoutManager to intialize traits
* for the areas it will create, based on Properties set on its FO.
*/
protected void initProperties(PropertyManager pm) {
System.err.println(AbstractBPLayoutManager.initProperties);
}
/**
* Tell whether this LayoutManager has handled all of its content.
* @return True if there are no more break possibilities,
* ie. the last one returned represents the end of the content.
*/
public boolean isFinished() {
return m_bFinished;
}
public void setFinished(boolean bFinished) {
m_bFinished = bFinished;
}
// /**
// * Get the BreakPoss at the start of the next area.
// * @param lc The LayoutContext for this LayoutManager.
// * @param bpPrevEnd The Position returned by the previous call
// * to getNextBreakPoss, or null if none.
// */
// public BreakPoss getStartBreakPoss(LayoutContext lc,
// BreakPoss.Position bpPrevEnd) {
//return null;
// }
/**
* Generate and return the next break possibility.
* Each layout manager must implement this.
* TODO: should this be abstract or is there some reasonable
* default implementation?
*/
public BreakPoss getNextBreakPoss(LayoutContext context) {
return getNextBreakPoss(context, null);
}
public BreakPoss getNextBreakPoss(LayoutContext context,
BreakPoss.Position prevBreakPoss) {
return null;
}
/**
* Return value indicating whether the next area to be generated could
* start a new line or flow area.
* In general, if can't break at the current level, delegate to
* the first child LM.
* NOTE: should only be called if the START_AREA flag is set in context,
* since the previous sibling LM must have returned a BreakPoss which
* does not allow break-after.
* QUESTION: in block-stacked areas, does this mean some kind of keep
* condition, or is it only used for inline-stacked areas?
* Default implementation always returns true.
*/
public boolean canBreakBefore(LayoutContext context) {
return true;
}
public void addAreas(PositionIterator parentIter) {
}
/* -
* PROVIDE NULL IMPLEMENTATIONS OF METHODS from LayoutManager
* interface which are declared abstract in AbstractLayoutManager.
* -*/
public Area getParentArea(Area childArea) {
return null;
}
protected boolean flush() {
return false;
}
public boolean addChild(Area childArea) {
return false;
}
}
1.1 xml-fop/src/org/apache/fop/layoutmgr/BPLayoutManager.java
Index: BPLayoutManager.java
PDF encryption
Hi all,
for the archives, I've written a small proof-of-concept
program which couples FOP and iText in order to provide
PDF encryption. Watermarking and everything else, possibly
even Henrik Holle's total page count problem, could be
done in a similar way.
Most of the iText code is directly copied from Lowagie's
enctryption utility.
Home page: http://www.lowagie.com/iText/
public static void main(String args[]) {
try {
ByteArrayOutputStream fopout=new ByteArrayOutputStream();
FileOutputStream outfile=new FileOutputStream(args[2]);
Driver driver =new Driver();
driver.setOutputStream(fopout);
driver.setRenderer(Driver.RENDER_PDF);
Transformer transformer=TransformerFactory.newInstance().newTransformer(new
StreamSource(new File(args[1])));
transformer.setParameter(page-count,#);
transformer.transform(new StreamSource(new File(args[0])), new
SAXResult(driver.getContentHandler()));
PdfReader reader = new PdfReader(fopout.toByteArray());
int n = reader.getNumberOfPages();
Document document = new Document(reader.getPageSizeWithRotation(1));
PdfWriter writer = PdfWriter.getInstance(document, outfile);
writer.setEncryption(PdfWriter.STRENGTH40BITS, pdf, null,
PdfWriter.AllowCopy);
document.open();
PdfContentByte cb = writer.getDirectContent();
PdfImportedPage page;
int rotation;
int i = 0;
while (i n) {
i++;
document.setPageSize(reader.getPageSizeWithRotation(i));
document.newPage();
page = writer.getImportedPage(reader, i);
rotation = reader.getPageRotation(i);
if (rotation == 90 || rotation == 270) {
cb.addTemplate(page, 0, -1f, 1f, 0, 0,
reader.getPageSizeWithRotation(i).height());
}
else {
cb.addTemplate(page, 1f, 0, 0, 1f, 0, 0);
}
System.out.println(Processed page + i);
}
document.close();
}
catch( Exception e) {
e.printStackTrace();
}
}
Have fun
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: PDF encryption
Geez, self-followup: writer.setEncryption(PdfWriter.STRENGTH40BITS, pdf, null, PdfWriter.AllowCopy); If I set encryption to STRENGTH128BITS, as the original had, Acrobat Reader 4.0 complains about Error while decrypting. Probably an export restriction :-(, so be careful. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
Arved, I think the ownership idea is a good one. Especially since we now have some new committers who are full of energy and we have a batch of new code in the redesign branch which people can (and should!) look at and respond to. I think we can start like this: a) review the code which Kerion and I have committed in the last couple of days. b) discuss it here on the list; if it would then seem useful to have a more instantaneous forum to work out issues, we can work on setting that up. c) parcel out work on the code to various owners. There's lot's to do, so no one should feel left out. d) Communicate on the list (I think it's better than using the Status file, more spontaneous) about what we intend to do in the next iteration (next couple of weeks say). We could use a specific tag line like [PLANNING UPDATE] or some such so these messages wouldn't get lost in the forest. Regards, Karen Arved Sandstrom wrote: I have some thoughts and suggestions, some of which we might adopt with varying degrees of success. 1. I can see a place for structured (that is, planned) communication: conference calls, scheduled meetings on a system like Peter describes, use of something like MSN Messenger, setting up an IRC channel and everyone getting together there. But I don't think that's the problem at the moment. 2. Can we do better with CVS? Maybe...reserved checkouts is overkill but perhaps watch features are indicated. We currently get commit notifications (I suspect through loginfo, probably, rather than a watch feature), but we don't know when someone started work on a file. If we used watches, we could set things up so Karen might get notifications on 'cvs edit' for such-and-such a package, Peter might get 'cvs edit' notifications on another package that he selects, and so forth, whatever is of interest. This would at least give us notifications at the other end of the process, which is when a developer (say, Keiron) _starts_ to work on a file. This is a bandaid, though. I am just as bad as Karen when it comes to wanting to have everything just-so before I check something in. This is OK with reserved checkout systems like SourceSafe default, but it's lousy for the unreserved checkout CVS case. I would nevertheless suggest maybe trying the watch features. I would otherwise really stress the use of a single-point-of-reference file, like STATUS, but I have my doubts about that. It has not proved out so far. What would be really sweet is if we had a visual aid that supplemented cvs watch features, maybe a page on the website that you could access that would indicate that a certain developer has run 'cvs edit' on file A, for example. Maybe ViewCVS does this already, I don't know. What we lack is ownership. We've got a whack of committers and a fair-few active ones, and maybe it's now time to allocate ownership of stuff on both branches. Ownership does _not_ mean you are the only person working in that package or packages - what it means is you are the POC for work being done in that package. You are the arbiter of disputes. We could even combine this with BugZilla ownership, possibly. Comments? If folks are agreed or at least not against it I can set up what needs to be setup. Arved -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Karen Lease Sent: April 27, 2002 12:20 PM To: [EMAIL PROTECTED] Subject: Re: line layout commit [ SNIP ] At any rate, I'm certainly not averse to having some more structured kind of communication about where to go from here be that a chat or just some discussion on the list of where we are and where we should go. As I mentioned, I'm going to dive in to his new stuff and study it carefully today and tomorrow; I'll probably have some questions and remarks at that point. [ SNIP ] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit (part 2)
Hi Foppers, I've gone ahead and committed the major part of the Break Possibility approach to layout managers which I have developped. It leaves Keiron's new code intact (except for a couple of changes I needed to make to be able to subclass his LineLayoutManager). It's also not activated; to do so there are two changes to make: org.apache.fop.fo.FOText: create a TextBPLayoutManager instead of a TextLayoutManager org.apache.fop.layoutmgr.BlockLayoutManager: create a LineBPLayoutManager instead of a LineLayoutManager Both changes are in comments. This code will run for blocks containing text but not much else. It's mostly just to illustrate the idea. I didn't try to work in the block-level versions of the BP layout managers, at least not for now. In most ways, it's a good deal less functional than Keiron's code; however it does have some code to handle resolution of sequences of space specifiers, and the text layout code has the start of some word-space handling. It might be helpful to have another look at the design document describing the general idea when looking at the code. Regards, Karen Keiron Liddle wrote: Hi Developers, I just committed a bunch of changes to the line layout. I think it now has a reasonable basis to further develop the inline level areas and build line areas. If you run it over alignment.fo or instream.fo you will see that it mostly works for these examples. It does the spacing and vertical alignment. [SNIP] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit (coments on Keiron's commit)
Hi Keiron, Here are a few comments on your new layoutmgr stuff (which is definitely more advanced than mine in most ways) : 1. I can't figure out how/where you manage space-start, space-end, border, padding, background etc (ie, any non-inherited properties) for non leaf node inline FO, ie: fo:inline and fo:basic-link. As you said, you're flattening the inline LM, so in fact, you're just adding the FO children of the inline. I think that if these FO _must_ create real inline areas if they have any non-inherited properties. If they don't they are acting kind of like fo:wrapper, and in that case, I agree we don't need a separate layout manager, because no area needs to be created. For basic-link, I think it would also be easier if it created an inline area containing its child areas even if it doesn't have any non-ineritable layout type properites. We could hang the linking information on that area (or areas, if it split across lines). But if we make nested inline areas, then the space adjustment as written in the LineLayoutManager won't work correctly, because it won't see the nested spaces. 2. Lack of context information: I ended up adding a LayoutContext oject to pass information down to the LM(s) generating the areas. This is to handle things like space-specifiers which can accumulate from various tree levels, and also to indicate when a LM is generating a break (or an Area) which is first in its parent area. That can influence things like conditional space and borders and padding. What's a pain with that stuff is that it changes the IPD, so until we know where the area is going to be placed, we don't know exactly how big it will be. 3. I'd like to avoid having to generate all the child LM before starting to layout any given level. This would limit us to waiting for a whole fo:flow to be done (unless we special case at that level). I think we can find a way to pull on the layout managers and still keep the flexibility you gain with the addLayoutManager(List) approach. I think it could be done with some kind of Iterator. (OK, I'm on kind of an Iterator fling recently, but they _are_ really handy. :-) Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
Arved Sandstrom wrote: What we lack is ownership. We could even combine this with BugZilla ownership, possibly. Creating an assigned bugzilla entry (ENH) works for other projects. I still think it's not quite sufficient for broad-scoped changes like the current redesign, but it might work well in the future when core changes will become more incremental again. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
Arved, See comments below. Arved Sandstrom wrote: 1. I can see a place for structured (that is, planned) communication: conference calls, scheduled meetings on a system like Peter describes, use of something like MSN Messenger, setting up an IRC channel and everyone getting together there. But I don't think that's the problem at the moment. The problem is going to be with the timing. Scheduling a regulat chat would be a good idea because folks can try to schedule around that and, who knows, it could get to be a habit. 2. Can we do better with CVS? ,,, If we used watches, we could set things up so Karen might get notifications on 'cvs edit' for such-and-such a package, Peter might get 'cvs edit' notifications on another package that he selects, and so forth, whatever is of interest. This would at least give us notifications at the other end of the process, which is when a developer (say, Keiron) _starts_ to work on a file. This is a bandaid, though. I am just as bad as Karen when it comes to wanting to have everything just-so before I check something in. This is OK with reserved checkout systems like SourceSafe default, but it's lousy for the unreserved checkout CVS case. Yes and no. I think that the motivation for the CVS model was dissatisfaction with the RCS/SCCS lock model in precisely these situations; multiple developers, with some in the process of lengthy modifcations. I'm with you and Karen on this. My flesh creeps at the idea of committing code which I know to be in a shambolic state. It's worse if I have to then merge in someone else's changes, then iterate over the whole process a couple of days later. The situation is worse at the moment because basic design issues are being worked out on the fly, so there are going to be large, incompatible areas of the code between Karen and Keiron until the design is settled. My design is even more incompatible, so when I check my code in, I will be setting up my own branch. It seems to me that Karen might productively branch her changes, and track what Keiron is doing by merging in from his code. Take the current issue with her subclassing of Keiron's code. She need not have the code commented out in her branch, and she can explore the issues in safety. When she has proven the concept, she can merge back into the trunk. I don't think she is going to be left behind, but if she cannot develop her ideas in relative isolation from other ongoing and incompatible changes, a lot of her time may be spent in tedious merging activity. I would nevertheless suggest maybe trying the watch features. Agreed What we lack is ownership. We've got a whack of committers and a fair-few active ones, and maybe it's now time to allocate ownership of stuff on both branches. Ownership does _not_ mean you are the only person working in that package or packages - what it means is you are the POC for work being done in that package. You are the arbiter of disputes. We could even combine this with BugZilla ownership, possibly. The only trouble I see with this is that the only ones who are really familiar with the code are also *very* busy with development, part-time. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Committing html
You'll get a disgruntled reply from Brian if you actually asked him on his personal email. :-) Stuff like this it's best to go to [EMAIL PROTECTED]; typically you'll end up talking to Manoj Kasichainula. Arved -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: April 28, 2002 7:58 PM To: fop-dev Subject: Committing html Fops all, I have committed changes to the web site into xml-site/targets/fop/design/alt.design and I would be most grateful if one of the committers could perform a cvs update on xml.apache.org. Why? Having set up ssh on cvs.apache.org, I promptly forgot my login password. Keiron, don't say a word... I have asked Brian to reset the password, but I don't know how long this will take. Tia, u Peter! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF encryption
Actually, 128 bit is a ver. 5.0 requirement. I'm using this exact setup in my app (iText w/ FOP for encryption), and we are requiring all users to have AcroReader 5.0 for 128 bit encryption. Also, if you encrypt at 128 bit, and then check the encryptions properties of the doc in Reader, you'll see strength 128 and next to it, 5.0 in parenthesis. -- David B. Bitton [EMAIL PROTECTED] www.codenoevil.com Code Made Fresh DailyT - Original Message - From: J.Pietschmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, April 28, 2002 5:39 PM Subject: Re: PDF encryption Geez, self-followup: writer.setEncryption(PdfWriter.STRENGTH40BITS, pdf, null, PdfWriter.AllowCopy); If I set encryption to STRENGTH128BITS, as the original had, Acrobat Reader 4.0 complains about Error while decrypting. Probably an export restriction :-(, so be careful. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
