headers
W. Eliot Kimber | 2 Nov 2002 13:37

Margins and Block Geometry


I'm trying to get a full understanding of block geometry and I think 
I've pretty much got it now but I must report that the initial 
discussion of block geometry in section 4.4.1, which I found to be 
pretty clear, is then completely thrown out the window by the discussion 
of margins in 5.3.2, in that the effect of margin specifications, which 
are not mentioned *before* 5.3.2, seemingly contradicts 4.4.1 in that 
4.4.1 says that the rectangles of a block are relative to (and only to) 
the content rectangle of the containing reference area. And by 
implication, are always *inside* of the containing reference area's 
content rectangle given positive or zero values for border, padding, and 
indent.

That is, given the information in 4.4.1 and this markup:

         <fo:block-container
           border-start-style="solid"
           border-start-width="1pt"
           border-start-color="red"
         >
         <fo:block
             border-start-style="solid"
             border-start-width="4pt"
             border-start-color="rgb(200, 100, 0)"
             padding-start="8pt"
             font-family="sans-serif"
             font-size="24pt"
             line-height="110%"
           >
(Continue reading)

Permalink | Reply | 0 comments |
headers
W. Eliot Kimber | 3 Nov 2002 23:22

How is Binding Edge Determined?


I noticed that text-align defines "outside" and "inside" in terms of the 
  "binding edge". However, I couldn't find any reference to "binding" or 
"bound" or "bind" outside of the discussion of text-align. Thus my 
question: how is the binding edge defined or determined? That is, I 
might have a normally oriented page (before is top) that is top-bound or 
I might, for some bizare reason, bind a left-to-right document on the right.

Have I missed something?

Thanks,

Eliot
--

-- 
W. Eliot Kimber, eliot <at> isogen.com
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139
Permalink | Reply | 0 comments |
headers
Heinz Grimm | 4 Nov 2002 13:54
Picon

fo:table, fo:table-row, Proposal for support of "big tables"

Hi,
We tried to use XSL-FO to create database reports. The biggest
problem was, that big tables are not supported by XSL-FO. Big
table means a table that has more rows and columns as can be
rendered on a single page. Appended is a proposal to extend the specs
of fo:table and fo:table-row to support big tables.

I am new to this list. As I understand this list intended to
submit proposals for XSL-FO 2.0 specs. Is there a web site,
where I can look what changes to XSL-FO 1.0 are already planned
or accepted?

Thank you,
Heinz Grimm

Proposal for support of "big tables"

fo:table
New values for property overflow:

next_row    start on next page with table-header and continue
            table with next row. Start eachn row with a row
            header(see sample (b))
next_column start on next page with table_header and continue
            table with next column. Start each row with a row
            header (see sample (a))

fo:table-row (fo:table-row-header?,fo:table-cell+)
New formating object fo:table-row-header
Similar to fo:table-header, preceeds each row of a table,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Max Froumentin | 4 Nov 2002 16:30
Picon
Favicon

Re: fo:table, fo:table-row, Proposal for support of "big tables"


Hi Heinz,

You wrote:

> I am new to this list. As I understand this list intended to
> submit proposals for XSL-FO 2.0 specs. Is there a web site,
> where I can look what changes to XSL-FO 1.0 are already planned
> or accepted?

Thank you for your proposal. This is the right list. The XSL Working
Group is indeed working on extensions to XSL-FO 1.0 and we will
consider your submission as well as others we receive on this list.

Cheers,

Max.
Permalink | Reply | 0 comments |
headers
Heinz Grimm | 5 Nov 2002 11:17
Picon

Proposal for modified specs of fo:footnote, fo:footnote-body

Hi,

Appended is a proposal for a different way to specify footnotes.
It allows to have several references to the same footnote.
The footnote should appear only, if there is a reference to
this footnote on the same page.

Kind Regards,
Heinz Grimm

The principle is to separate fo:footnote-body from fo:footnote.
fo:footnote-body should be an initial child of fo:block. It is
rendered on a page, if the same page has a fo:footnote with the
same number. Both, fo:footnote and fo:footnote-body have a
new property "number" to reference each other.

Sample FO:

<fo:block>
<fo:footnote-body number="*">
 <fo:block>exceeds tolerance limit 1%</fo:block>
</fo:footnote-body>
<fo:footnote-body number="**">
 <fo:block>exceeds tolerance limit 5%</fo:block>
</fo:footnote-body>
<fo:table>
 <fo:table-body>
  <fo:table-row>
   <fo:table-cell>
    <fo:block> 1 <fo:footnote
(Continue reading)

Permalink | Reply | 0 comments |
headers
W. Eliot Kimber | 5 Nov 2002 17:43

Tables Don't Respect Reference Orientation--why?


I notice that the spec says that only writing mode determines the cell 
and row progression order. I'm wondering why this is--I can't 
immediately think of any reason that tables shouldn't be rotatable just 
as any other reference area is--that is, the interaction of writing-mode 
with reference-orientation seems no more complex in a table context than 
in a multi-column page context, for example.

Have I missed some hidden complexity?

Thanks,

Eliot
--

-- 
W. Eliot Kimber, eliot <at> isogen.com
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139
Permalink | Reply | 0 comments |
headers
W. Eliot Kimber | 5 Nov 2002 19:20

Table Rotation Continued


Am I correct in my analysis that the reason that reference-orientation 
is not provided on table cell is that the calculation of the block and 
inline dimensions would just be too freaky when applying auto layout?

Thanks,

Eliot
--

-- 
W. Eliot Kimber, eliot <at> isogen.com
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139
Permalink | Reply | 0 comments |
headers
KirnSha | 6 Nov 2002 00:43
Picon
Favicon

RE: conflict resolution suggestion for XSLT


Hi,
    If 2 templates match is there a way to execute both templates instead of 
just executing the template that wins.

    In rule based programming if 2 rules have a match, first the rule with 
higher salience or specificity fires then the one with lower salience.

    In XSLT the higher priority rule fires and the lower priority rule is 
ignored.

    I recommend that there be a mechanism to allow all templates that match 
to execute be executed.

     Also does XSLT require stylesheet processors to use the RETE algorithm?

    Thanks
        Dhruv
Permalink | Reply | 1 comment |
headers
KirnSha | 6 Nov 2002 00:52
Picon
Favicon

RE: conflict resolution suggestion for XSLT


In regards to apply-imports the XSLT 2.0 spec specifically states in section 
6.6 all templates with lower precendence are not considered.

NOTE: This is not the same as saying that the search considers all template 
rules whose import precedence is lower than that of the current template rule.

I am requesting that all templates that are in conflict fire instead of the 
one with highest priority, and that priority only controls the order of the 
firing.

if this requires more overhead for XSLT processors the RETE algorithm could 
remedy that.
Permalink | Reply | 0 comments |
headers
Éric Bischoff | 6 Nov 2002 10:52
Picon

Re: XSL Errata document updated


Le Saturday 26 October 2002 13:27, Éric Bischoff a écrit:
> Le Saturday 26 October 2002 11:53, Dave Pawson a écrit:
> > Is this an offer to propose the necessary amendments Eric?
>
> I was waiting for this one ;-).
>
> If the committee is interested in such a work, I can consider doing it.

Not even a "no thanks" answer.

Please consider this contribution offer as closed.

--

-- 
- Do you know the four basic nutrition groups?
- Errr... Hamburger, soda, French fries and dessert?
Permalink | Reply | 0 comments |

Gmane