RE: [REDESIGN] Line layout manager discussion

[Arnd Beißner]

Keiron Liddle wrote:

> On Sat, 2002-05-04 at 18:07, Arved Sandstrom wrote:
> > I couldn't tell from the SVG source what you prepared the file with. I 
would
> > like to use SVG myself. There is no way I am going to handcode it, 
though
> > (just as with FO).
>
> I actually wrote it by hand.
> I tried using an editor but gave up, instead I just edit by hand and
> view it using batik. In this case it was fairly easy since everything is
> placed in a definite position.

Editing SVG with Adobe Illustrator 10 works ok (small wonder), though the 
licence is
fairly expensive if you don't use it regularly. The drawing app in 
OpenOffice may
have SVG export, too - I heard, but didn't check myself.

Fallback: If you send me design documents in vector graphics files of 
(almost)
any kind, I can do the SVG conversion for you. I'm in office even on most 
weekends
so this may work ok for some time.

Arnd Beissner
--
Cappelino Informationstechnologie GmbH
Arnd Beißner
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [REDESIGN] Line layout manager discussion

[Keiron Liddle]

On Sat, 2002-05-04 at 18:07, Arved Sandstrom wrote:
> I couldn't tell from the SVG source what you prepared the file with. I would
> like to use SVG myself. There is no way I am going to handcode it, though
> (just as with FO).

I actually wrote it by hand.
I tried using an editor but gave up, instead I just edit by hand and
view it using batik. In this case it was fairly easy since everything is
placed in a definite position.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [REDESIGN] Line layout manager discussion

[Peter B. West]

Arved,

Again, I agree that, in the conceptual area tree described in the spec, 
blocks embedded in inline-area generating FOs in the fo tree (e.g., 
fo:inline and fo:basic-link), themselves embedded in a parent fo:block, 
do not bubble up to the same level as the parent fo:block.  Going back 
to your diagram, I am talking about the fo:block embedded in the 
basic-link.  I have attached another diagram describing a subset of your 
original example.

Let me clarify what I meant by the term "bubble up" in the reply to Karen.

"Then what seems to me to be the *intention* that layout within 
fo:inline and fo:basic-link proceed as though these wrappers were 
layout-transparent, would be made clear. That is, blocks bubbling up 
from below will be stacked in the BPDir without IPDir attachments from 
surrounding inline-areas."

This refers to the spec's conceptual area tree.  It arises out of my 
misapprehension that the nesting of fo:blocks within inline-area 
generators would involve a nesting of the layout within the generated 
inline-area.  The fo:inline inline-area in the area tree would grow 
within the bounds of the containing line-area and block area, but 
limited by it.

It doesn't work that way, though, as we have all discussed.  These block 
areas "bubble-up", not in terms of their containment within the 
appropriate set of line-area->inline-area->block-area, bu in terms of 
their layout consequences.  Apart from any layout-altering properties 
defined on the containing inline-area generator, e.g.font or border 
changes, the text and any nested blocks are treated for layout as though 
they had occurred as direct children of the outer fo:block.  That's what 
the term "layout-transparent" means.

That, at least, is what I take the *intention* of the authors to be. 
 And that is why I want to see some clarification of the relationship 
between 4.7.2 Line-building and 4.7.3 Inline-building.  It seems to me 
that the spec decrees that the initial text of the basic-link ("In 
basic-link " in my example) is constructed into an inline-area by the 
Inline-building process of 4.7.3.  In order to do this, it has to know 
about the constraints that it inherits from the already partially 
constructed line-area which contains "Text in block ".  It seems to me 
that, conceptually at least, in the conceptual area tree model of the 
spec, the inline-building process needs to take account of all of the 
glyph substitution, insertion and deletion considerations that apply to 
4.7.2, because it is now the responsibility of the inline-area generator 
to generate a *single* inline-area to complete the pending line-area of 
the parent.  To do that, it will have to be able to do its own 
line-breaking.

Clarifying this is a matter of the coherence and consistency of the 
spec.  It is also important if you are tempted, as I am, by the idea of 
mimicking this conceptual model and procedure in actual code.

All of the above may just mean that, while I thought I had been brought 
around to your way of thinking on this aspect of the spec, I may still 
be thinking about it very differently.

Peter

Arved Sandstrom wrote:

>My last post was motivated by one thing - the statement that a block area
>"bubbles up". Well, it does not, not in the conceptual area tree described
>in the XSL spec. As a result I thought it worth our time to ask for some
>specificity when the area tree being referred to is not immediately obvious.
>
>I agree with your sentiments, particularly the last sentence. As such I
>think it is very important to establish exactly what area tree we are
>talking about in any given context. In theory there are at least 2 - the XSL
>1.0 conceptual area tree, and the real "tree" (really, whatever structure we
>happen to use). There could be more.
>
>  
>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Border properties

[Arved Sandstrom]

Comments intermingled.Default reference orientation and lr-tb writing mode
assumed.

> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: May 5, 2002 1:34 PM
> To: fop dev
> Subject: Border properties
>
> Hello,
> I tried to make something out of bug 684. Again, after
> reading the spec in depth, I'm nearly biting pieces off
> my keyboard.
> In the tables.fo examples, the left edge of the table
> content rectangle is the same as the edge of the reference
> area, and left border (should I use "start edge border"?)
> is tacked on so that it extends outside the reference area.

What it really boils down to is, the start-indent and end-indent are
content-rectangle to content-rectangle distances. If the start-indent is
zero then borders and padding and space are outside the content rectangle of
the reference area. Similarly for end-indent.

> The upper and lower border, however, do not overlap previous
> or following blocks, as expected.

I would not expect this - see below. At least not with initial values.

> Well 4.4.1 says
>   the start-edge of its allocation-rectangle ... offset from it
>   inward by a distance equal to the block-area's start-indent
>   plus its start-intrusion-adjustment (as defined below)
>   minus its border-start, padding-start, and space-start values...
> given that the start-indent of the tables are zero (hopefully),
> the behaviour regarding the border extending left beyond the
> edge of the refernce area appears to be consistent with the spec,
> albeit IMO a bit counter-intuitive, because not consistent with
> what happens in BPD.

The treatment is different; there is no BPD counterpart to start-indent and
end-indent. The separation between content-rectangles is determined by
padding+border+space (before & after).

Borders and padding are  values so unless they are at
the leading or trailing edge of a reference area they will definitely have
the specified . None of them are negative. The spaces _can_ be
negative so this is the sole mechanism by which areas (including borders &
padding) can overlap (and space-specifier resolution is involved of course).

> Now, what is the problem bug 684 complains about? Does it mean
> the border in BPD should be handled similarly to what happens in
> IPD? Or does he mean something else?
> And, of course: is my understanding on how borders/padding should
> be handled resonable? I feel very confused.

Join the club. :-) I constantly remind myself of what the definitions really
mean in simple language. I also try to minimize use of allocation
rectangles - I understand the concept but find it confusing.

> BTW what happens if both start-indent and margin-start were
> defined on the same block area?

margin-* properties are absolute only (top, bottom, left, right). In any
case, according to 5.3.2 and 5.3.1 the absolute properties take precedence.
margin-left if explicitly specified has priority over start-indent.

I took a quick look at table.fo (the FO) and I think this will probably help
out. I have to admit if there is one area of the spec that I am not
particularly familiar with it is tables - in this case I don't think there
is any weirdness involved stemming from table border properties.

Regards,
Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 1759] - table-omit-footer-at-break sometimes cause crash

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1759

table-omit-footer-at-break sometimes cause crash

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 OS/Version||All
   Priority||High
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-05-05 20:29 ---
No crash nor a warning with 0.20.3. I assume the problem is fixed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 1474] - fo:external-graphic rendered as block level object

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1474

fo:external-graphic rendered as block level object

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-05-05 19:52 ---
Fixed in 0.20.3, even the line height is adjusted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 1391] - Bug in border-top-style

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1391

Bug in border-top-style

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 OS/Version||All
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-05-05 19:45 ---
Can't reproduce the problem with 0.20.3.
A complete testcase would have helped.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 1318] - problems with tables (column width and when used in the xsl-after-region)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1318

problems with tables (column width and when used in the xsl-after-region)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-05-05 19:28 ---
Both problems are fixed in 0.20.3

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 1261] - problem with rendering of external-graphic in Fop-18

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1261

problem with rendering of external-graphic in Fop-18

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-05-05 17:35 ---
The test case works in 0.20.3

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 1154] - nested lists more than 3 level depth

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1154

nested lists more than 3 level depth

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Priority||High
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-05-05 17:24 ---
Nested lists four levels deep appear to work in 0.20.3
A test case would have helped.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Bug report for Fop [2002/05/05]

[bugzilla]

+---+
| 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  |
| |   |   |  |  |
|  635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence |
|  664|Opn|Nor|2001-02-21|Basic-Link does not move with its content, when us|
|  684|New|Nor|2001-02-23|border width in tables adds up|
|  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|
|  928|New|Nor|2001-03-10|Font metrics and setComponent |
| 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  |
| 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|
| 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 |
| 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-|
| 3007|New|Nor|2001-08-06|broken basic-link when referencing a following pag|
| 3044|Ass|Maj|2001-08-08|keep-together not functioning |
| 3061|New|Nor|2001-08-09|Link 'click' location doesn't take padding-top int|
| 3073|New|Nor|2001-08-10|Whitespace does not scale |
| 3116|New|Nor|2001-08-14|0.19.0 Error on IE5 refresh with external graphics|
| 3208|New|Nor|2001-08-21|Blocks aligned incorrectly in PDF |
| 3215|New|Nor|2001-08-21|fo:leader with a percentage as leader-length does |
| 3216|New|Enh|2001-08-21|break-after="page" throws a break when page is ful|
| 3258|New|Nor|2001-

DO NOT REPLY [Bug 8816] New: - content for xsl-footnote-separator doesn't work

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8816

content  for xsl-footnote-separator  doesn't work

   Summary: content  for xsl-footnote-separator  doesn't work
   Product: Fop
   Version: 0.20.3
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: page-master/layout
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Defining static content for the xsl-footnote-separator as specified in
6.10.1.3 doesn't work.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 8815] New: - Irritating overlapping regions in examples

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8815

Irritating overlapping regions in examples

   Summary: Irritating overlapping regions in examples
   Product: Fop
   Version: 0.20.3
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Many of the examples distributed with FOP define a region-after but don't
set corresponding margin-bottom, thereby creating overlapping regions.
This could irritate users.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Border properties

[J.Pietschmann]

Hello,
I tried to make something out of bug 684. Again, after
reading the spec in depth, I'm nearly biting pieces off
my keyboard.
In the tables.fo examples, the left edge of the table
content rectangle is the same as the edge of the reference
area, and left border (should I use "start edge border"?)
is tacked on so that it extends outside the reference area.
The upper and lower border, however, do not overlap previous
or following blocks, as expected.
Well 4.4.1 says
  the start-edge of its allocation-rectangle ... offset from it
  inward by a distance equal to the block-area's start-indent
  plus its start-intrusion-adjustment (as defined below)
  minus its border-start, padding-start, and space-start values...
given that the start-indent of the tables are zero (hopefully),
the behaviour regarding the border extending left beyond the
edge of the refernce area appears to be consistent with the spec,
albeit IMO a bit counter-intuitive, because not consistent with
what happens in BPD.

Now, what is the problem bug 684 complains about? Does it mean
the border in BPD should be handled similarly to what happens in
IPD? Or does he mean something else?
And, of course: is my understanding on how borders/padding should
be handled resonable? I feel very confused.

BTW what happens if both start-indent and margin-start were
defined on the same block area?

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop STATUS

[jeremias]

jeremias02/05/05 08:52:35

  Modified:.STATUS
  Log:
  Updated committer list.
  
  Revision  ChangesPath
  1.49  +8 -3  xml-fop/STATUS
  
  Index: STATUS
  ===
  RCS file: /home/cvs/xml-fop/STATUS,v
  retrieving revision 1.48
  retrieving revision 1.49
  diff -u -r1.48 -r1.49
  --- STATUS5 Mar 2002 14:39:45 -   1.48
  +++ STATUS5 May 2002 15:52:34 -   1.49
  @@ -4,16 +4,21 @@
   James Tauber (started it all and wrote most of the code) 
   
   Kelly Campbell
  -Steven Coffman 
  +Steven Coffman
  +Bertrand Delacretaz
  +Tore Engvig
  +Christian Geisert
   Stanislav Gorkhover
   Fotis Jannidis 
   Karen Lease
   Keiron Liddle
  +Jeremias Maerki
   Jordan Naftolin
  +Joerg Pietschmann
   Eric Schaeffer 
   Jon Smirl 
  -Christian Geisert
  -Bertrand Delacretaz
  +Art Welch
  +Peter B. West
   
   Initial development of new layout managers, area tree and renderers.
   Altered xml handling.
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: xml-fop STATUS

[jeremias]

jeremias02/05/05 08:49:50

  Modified:.Tag: fop-0_20_2-maintain STATUS
  Log:
  Updated committer list.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.47.2.2  +3 -0  xml-fop/STATUS
  
  Index: STATUS
  ===
  RCS file: /home/cvs/xml-fop/STATUS,v
  retrieving revision 1.47.2.1
  retrieving revision 1.47.2.2
  diff -u -r1.47.2.1 -r1.47.2.2
  --- STATUS18 Feb 2002 18:27:36 -  1.47.2.1
  +++ STATUS5 May 2002 15:49:50 -   1.47.2.2
  @@ -12,10 +12,13 @@
   Fotis Jannidis 
   Karen Lease
   Keiron Liddle
  +Jeremias Maerki
   Jordan Naftolin
  +Joerg Pietschmann
   Eric Schaeffer 
   Jon Smirl 
   Art Welch
  +Peter B. West
   
    THINGS WORKED ON * 
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Master reference for fo:page-sequence

[Jeremias Maerki]

Thanks. This is now fixed in CVS (Yeah, my first commit!). The two files
were already updated for the redesign but not in the maintenance branch.

On 03.05.2002 18:20:06 Buchtík, Michal wrote:
> There are
> docs/xml2pdf.xsl
> docs/xml-docs/xml2pdf.xsl
> 
> in fop-0.20.2-maintain branch with master-name attribute in page-sequence
> tag.
> 
> 
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 03, 2002 5:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Master reference for fo:page-sequence
> 
> 
> If there are still any examples left in the current distribution would
> you please point out which? All examples should have been upgraded by
> now. Are you sure you don't have any old files in your FOP directory?
> 
> On 03.05.2002 11:05:51 claes.bergsten wrote:
> > 
> > Thanks missed that one.
> > Maybe should fix that in the examples provided.
> > 
> > Claes
> > 
> > Your stylesheet still uses pre-Recommendation XSL:FO. Please see the
> > release notes for instructions to resolve this:
> > http://xml.apache.org/fop/relnotes.html
> > 
> > > When trying to process my fo-file I get the following error:
> > > FATAL ERROR: 'master-reference' for 'fo:page-sequence'matches no
> > > 'simple-page-master' or 'page-sequence-master'


Cheers,
Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: cvs commit: xml-fop/docs/xml-docs xml2pdf.xsl

[dirkx]

Sorry for the delay - this got stuck in a moderator queue - and I missed
it as it had the same size, down to the last byte, as a spam message I got
on -all- asf accounts.

Dw

-- 
Dirk-Willem van Gulik

On 5 May 2002 [EMAIL PROTECTED] wrote:

> jeremias02/05/05 05:17:42
>
>   Modified:docs Tag: fop-0_20_2-maintain xml2pdf.xsl
>docs/xml-docs Tag: fop-0_20_2-maintain xml2pdf.xsl
>   Log:
>   Changed master-name to master-reference.
>
>   Revision  ChangesPath
>   No   revision
>
>
>   No   revision
>
>
>   1.4.4.1   +1 -1  xml-fop/docs/xml2pdf.xsl
>
>   Index: xml2pdf.xsl
>   ===
>   RCS file: /home/cvs/xml-fop/docs/xml2pdf.xsl,v
>   retrieving revision 1.4
>   retrieving revision 1.4.4.1
>   diff -u -r1.4 -r1.4.4.1
>   --- xml2pdf.xsl 16 Dec 2000 22:48:48 -  1.4
>   +++ xml2pdf.xsl 5 May 2002 12:17:41 -   1.4.4.1
>   @@ -21,7 +21,7 @@
>   
>   
>
>   -   
>   +   
>   
>  font-size="10pt"
>
>
>
>   No   revision
>
>
>   No   revision
>
>
>   1.9.2.1   +1 -1  xml-fop/docs/xml-docs/xml2pdf.xsl
>
>   Index: xml2pdf.xsl
>   ===
>   RCS file: /home/cvs/xml-fop/docs/xml-docs/xml2pdf.xsl,v
>   retrieving revision 1.9
>   retrieving revision 1.9.2.1
>   diff -u -r1.9 -r1.9.2.1
>   --- xml2pdf.xsl 20 Aug 2001 16:19:58 -  1.9
>   +++ xml2pdf.xsl 5 May 2002 12:17:41 -   1.9.2.1
>   @@ -37,7 +37,7 @@
>   
>   
>
>   -   
>   +   
>   
>  font-size="10pt"
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/docs/xml-docs xml2pdf.xsl

[jeremias]

jeremias02/05/05 05:17:42

  Modified:docs Tag: fop-0_20_2-maintain xml2pdf.xsl
   docs/xml-docs Tag: fop-0_20_2-maintain xml2pdf.xsl
  Log:
  Changed master-name to master-reference.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.4.4.1   +1 -1  xml-fop/docs/xml2pdf.xsl
  
  Index: xml2pdf.xsl
  ===
  RCS file: /home/cvs/xml-fop/docs/xml2pdf.xsl,v
  retrieving revision 1.4
  retrieving revision 1.4.4.1
  diff -u -r1.4 -r1.4.4.1
  --- xml2pdf.xsl   16 Dec 2000 22:48:48 -  1.4
  +++ xml2pdf.xsl   5 May 2002 12:17:41 -   1.4.4.1
  @@ -21,7 +21,7 @@


   
  - 
  + 



   
  - 
  + 

RE: [REDESIGN] Line layout manager discussion

[Arved Sandstrom]

> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]]
> Sent: May 5, 2002 12:55 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [REDESIGN] Line layout manager discussion
>
>
> Arved,
>
> I agree that there is no need to tie the rendering to any particular
> model, as long as the results are equivalent.  The discussions that span
> this list and the Xslfo-proc-devel list testify that there are many
> approaches to process of layout.  However, if I am reading this
> correctly, the proposal is to clarify the text of the spec.  In that
> context, the treatment of the area tree and its relationship to the fo
> tree must be coherent and consistent, or we will be in even deeper
> difficulties.
>
> Peter

My last post was motivated by one thing - the statement that a block area
"bubbles up". Well, it does not, not in the conceptual area tree described
in the XSL spec. As a result I thought it worth our time to ask for some
specificity when the area tree being referred to is not immediately obvious.

I agree with your sentiments, particularly the last sentence. As such I
think it is very important to establish exactly what area tree we are
talking about in any given context. In theory there are at least 2 - the XSL
1.0 conceptual area tree, and the real "tree" (really, whatever structure we
happen to use). There could be more.

Regards,
Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [REDESIGN] Line layout manager discussion

[Peter B. West]

Arved,

I agree that there is no need to tie the rendering to any particular 
model, as long as the results are equivalent.  The discussions that span 
this list and the Xslfo-proc-devel list testify that there are many 
approaches to process of layout.  However, if I am reading this 
correctly, the proposal is to clarify the text of the spec.  In that 
context, the treatment of the area tree and its relationship to the fo 
tree must be coherent and consistent, or we will be in even deeper 
difficulties.

Peter

Arved Sandstrom wrote:

>> From what I see here you are changing the shape of the tree.  The
>>motivation seems to be to make it explicit that block areas contained
>>within an inline area must bubble up to become direct children of the
>>containing block area.  I can't see that that is feasible, given the
>>basic design principle of the spec that the area tree follows the fo
>>tree.
>>
>[ SNIP ]
>
>With respect to the second sentence of the above, I think we should be very
>clear at all times about exactly which area tree we are talking about - the
>conceptual area tree as described in the spec, or the real one constructed
>by Fop.
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]