irene23 | 1 Jan 2008 22:26
Picon
Picon
Favicon

page-position="last" doesn't work for 1 page document


Hello,

I have two page-masters defined, with one having a different footer than the
other.

When this renders to a 2+ page document, the last page gets the last footer
and the other pages get the other footer.

When it renders to a 1 page document, I get the "any" page footer, even
though the the page is the last page....

I've posted on nabble.com, and gotten replies that it is possibly a bug.

 
<fo:layout-master-set> 
  <fo:simple-page-master master-name="default-page" 
                         page-height="11in" 
                         page-width="8.50in" 
                         margin-top="0.25in" 
                         margin-left="0.25in" 
                         margin-right="0.25in" 
                         margin-bottom="0.25in"> 
<!-- space needed for header & footer tables --> 
  <fo:region-body           
   region-name="body" 
   margin-top="0in" 
                         margin-bottom="1.50in"/> 
  <fo:region-before region-name="header" extent="10.0in"/> <!-- space needed 
for header table --> 
(Continue reading)

Meet Ahmed | 7 Jan 2008 17:13
Picon

Re: page-position="last" doesn't work for 1 page document

Yes you are right irene23
I admit
Regards
Ahmed

On Jan 2, 2008 2:26 AM, irene23 <basura2400 <at> yahoo.es> wrote:

Hello,

I have two page-masters defined, with one having a different footer than the
other.

When this renders to a 2+ page document, the last page gets the last footer
and the other pages get the other footer.

When it renders to a 1 page document, I get the "any" page footer, even
though the the page is the last page....

I've posted on nabble.com, and gotten replies that it is possibly a bug.


<fo:layout-master-set>
 <fo:simple-page-master master-name="default-page"
                        page-height="11in"
                        page-width="8.50in"
                        margin-top="0.25in"
                        margin-left="0.25in"
                        margin-right="0.25in"
                        margin-bottom=" 0.25in">
<!-- space needed for header & footer tables -->
 <fo:region-body
  region-name="body"
  margin-top="0in"
                        margin-bottom="1.50in "/>
 <fo:region-before region-name="header" extent="10.0in"/> <!-- space needed
for header table -->
 <fo:region-after region-name="footer" extent="1.50in "/> <!-- space needed
for footer table -->
 <fo:region-start  extent="0.00in"/>
 <fo:region-end    extent="0.00in"/>
 </fo:simple-page-master>


 <fo:simple-page-master master-name="last-page"
  page-height="11in"
  page-width="8.50in"
  margin-top="0.25in"
  margin-left="0.25in"
  margin-right=" 0.25in"
  margin-bottom="0.25in">
  <!-- space needed for header & footer tables -->
  <fo:region-body
   region-name="body"
   margin-top="0in"
   margin-bottom=" 1.50in"/>
  <fo:region-before region-name="header" extent="10.0in"/> <!-- space
needed
for header table -->
  <fo:region-after  region-name="last-footer" extent=" 1.50in"/> <!-- space
needed for footer table -->
  <fo:region-start  extent="0.00in"/>
  <fo:region-end    extent="0.00in"/>
 </fo:simple-page-master>


 <fo:page-sequence-master master-name="all">
  <fo:repeatable-page-master-alternatives>

   <fo:conditional-page-master-reference
    page-position="last" master-reference="last-page"/>

   <fo:conditional-page-master-reference
    page-position="any" master-reference="default-page" />

  </fo:repeatable-page-master-alternatives>
 </fo:page-sequence-master>
</fo:layout-master-set>

Can I get the same in other way? (With a footnote, or a block placed at the
end of the body...)

Could you help me?

Thank you very much.

-- 
http://www.ip2lookup.com
http://a.com.pk
 

Vincent Hennebert | 28 Jan 2008 17:15
Favicon

Explicit Row Height, table-cell’s Borders and border-separation


Dear XSL Editors,

As far as I can tell the XSL-FO 1.1 Recommendation doesn’t indicate 
whether an explicit height set on a table-row element should include the 
table’s border-separation and the children cells’ border widths, or not. 
In section 7.15.6, a reference to CSS 2 is made “for a discussion of the 
‘height’ property in tables”, but the CSS 2 Recommendation is itself not 
clear what the height of a cell should be in this context.

Also, in section 6.7.9, “fo:table-row”, the “row-height trait” is 
mentioned but is not referenced anywhere else.

So, in the following example:
    <fo:table table-layout="fixed" width="100%" 
      border-collapse="separate"
      border="1pt solid black"
      border-separation="6pt">
      <fo:table-body font-size="8pt" line-height="10pt">
        <fo:table-row block-progression-dimension="45pt">
          <fo:table-cell border="2pt solid black">
            <fo:block>Cell 1</fo:block>
          </fo:table-cell>
          <fo:table-cell border="5pt solid black">
            <fo:block>Cell 2</fo:block>
          </fo:table-cell>
        </fo:table-row>
      </fo:table-body>
    </fo:table>

What should be the final block-progression-dimensions for the cells?
There are 3 possibilities:
1. the explicit row height shall include the cells’ borders and the 
   table’s border-separation:
   - height of cell 1 = 3 (half of border-separation)
            + 2 (border-before)
            + 10 (b-p-d)
            + 2 (border-after)
            + 3 (half of border-separation)
            = 20pt
   - height of cell 2 = 3 + 5 + 10 + 5 + 3 = 26pt  
   - height of row = max(explicit row height, height of cell 1, height of cell 2)
                   = 45pt
   As a consequence the final block-progression-dimensions of the cells 
   are re-evaluated to match the row’s explicit height:
   - b-p-d of cell 1 = 45 - (3 + 2 + 2 + 3) = 35pt
   - b-p-d of cell 2 = 45 - (3 + 5 + 5 + 3) = 29pt

2. the explicit row height shall include the cells’ borders but not the 
   table’s border-separation:
   - height of cell 1 = 2 + 10 + 2 = 14pt
   - height of cell 2 = 5 + 10 + 5 = 20pt
   - height of row = max(45, 14, 20) = 45pt
   So the final block-progression-dimensions of the cells would be:
   - b-p-d of cell 1 = 45 - (2 + 2) = 41pt
   - b-p-d of cell 2 = 45 - (5 + 5) = 35pt

3. the explicit row height shall include only the cells’ 
   block-progression-dimensions:
   - height of cell 1 = 10pt
   - height of cell 2 = 10pt
   - height of row = max(45, 10, 10) = 45pt
   So the final block-progression-dimensions of the cells would be:
   - b-p-d of cell 1 = 45pt
   - b-p-d of cell 2 = 45pt
   But then what would be the final row height? Should it be re-computed 
   as in the case where the row height is left to auto? Then:
   - height of cell 1 = 2 + 45 + 2 = 49pt
   - height of cell 2 = 5 + 45 + 5 = 55pt
   - height of row = max(49, 55) = 55pt
   So final b-p-ds of the cells:
   - b-p-d of cell 1 = 55 - (2 + 2) = 51pt
   - b-p-d of cell 2 = 45pt

There are some hints in the Recommendation which would tend towards 
solution #2, but a clarification in this area would be much appreciated.

Thanks,
Vincent Hennebert

--

-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Vincent Hennebert | 28 Jan 2008 21:28
Favicon

Tables, space-start and border-separation

Dear XSL Editors,

The XSL-FO 1.1 Recommendation gives some details about how the 
border-separation property for tables should be handled, but it is not 
clear in my opinion where the half of it associated to the table should 
lie.

As a picture is still the simplest way to illustrate the problem, please 
have a look at the following example and the attached picture (see below 
for the formulas):
    <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
      <fo:layout-master-set>
        <fo:simple-page-master master-name="page"
          page-height="10cm" page-width="15cm" margin="1cm">
          <fo:region-body background-color="#ffc000"/>
        </fo:simple-page-master>
      </fo:layout-master-set>
      <fo:page-sequence master-reference="page" font-size="12pt">
        <fo:flow flow-name="xsl-region-body">
          <fo:table width="100%" table-layout="fixed"
            border-collapse="separate"
            border-separation="8pt" border="4pt solid black">
            <fo:table-column number-columns-repeated="2"
              column-width="proportional-column-width(1)"/>
            <fo:table-body>
              <fo:table-row>
                <fo:table-cell border="4pt solid black">
                  <fo:block>Cell 1</fo:block>
                </fo:table-cell>
                <fo:table-cell border="4pt solid black">
                  <fo:block>Cell 2</fo:block>
                </fo:table-cell>
              </fo:table-row>
            </fo:table-body>
          </fo:table>
        </fo:flow>
      </fo:page-sequence>
    </fo:root>

So, in the attached picture, which version is correct?

First, in section 4.4.1, “Stacked Block-areas”, the graphic shows 
a space-start trait but it is explained nowhere how its value should be 
computed. From the graphic we can infer the following formula:
    space-start = start-indent − border-start − padding-start
Still, it is not clear whether we are referring to traits or properties 
for border and padding. If I’m correct the padding-start property always  
directly maps to the padding-start trait. But this may not be the case 
for border-start, see below. So, let’s assume the following:

    (1) space-start(trait) = start-indent − border-start(trait) − padding-start

(Let’s note that Section 4.2.2 does not define any trait called 
start-indent, so this is always the property which will be used.)

Then Section 4.2.3, “Geometric Definitions”, states that, for 
block-level areas, “the allocation-rectangle extends [...] outside the 
content-rectangle in the inline-progression-direction by an amount equal 
to the end-indent, and in the opposite direction by an amount equal to 
the start-indent.”

For simplicity, let’s assume that the writing direction never changes. 
Given a block-area B, let’s call xa the offset of the start-edge of its 
allocation rectangle from the start-edge of the content-rectangle of its 
closest ancestor reference-area. Likewise, let’s call xc the offset of 
the start-edge of its content-rectangle.

Section 4.2.3 states that:
    (2) xa = xc − start-indent

Then Section 4.4.1 states that:
        xa = start-indent + start-intrusion-adjustment
             − border-start − padding-start − space-start
Since this section is all about traits, let’s assume we have the 
following:
    (3) xa = start-indent + start-intrusion-adjustment
             − border-start(trait) − padding-start 
             − space-start

But since space-start can be inferred from start-indent thanks to 
equation (2), we can simplify (3) into the following:
        xa = start-indent + start-intrusion-adjustment
             − border-start(trait) − padding-start 
             − (start-indent − border-start(trait) − padding-start)
which will simplify into the following:
        xa = start-intrusion-adjustment
and
        xc = start-intrusion-adjustment + start-indent
which means that if start-indent = 0, then the start-edge of B’s 
content-rectangle will coincide with the start-edge of the 
content-rectangle of the closest ancestor reference-area.

Buth then, why having kept the formula in its original, unsimplified 
form?

Now about tables. Section 6.7.3, “fo:table” says that in the separate 
border model the border of the table is composed of half the value of 
the border-separation property plus the border as specified by the 
property. Which would mean that the border-start(trait) would, in this 
particular case, be different from the border-start(property):
    border-start(trait) = border-start(property) + border-separation.inline-progression-dimension / 2

That’s why it seems important to me to know whether we are speaking of 
traits or properties in the formulas above. If both formulas use the 
same value (trait or property), then we have the result #1 on the 
attached picture. If formula (1) uses the trait and formula (3) uses the 
property, then the simplification will give:
    xa = start-indent + start-intrusion-adjustment
         − border-start(property) − padding-start 
         − (start-indent − border-start(trait) − padding-start)
       = start-intrusion-adjustment + border-separation.i-p-d / 2
Leading to result #2 in the attached picture, which is a sensible 
result.

And if formula (1) uses the property and formula (3) the trait, we get 
result #3 which is probably less likely to be expected.

Finally, Section 6.7.3, “fo:table” and Section 6.7.10, “fo:table-cell” 
mention the “table grid boundary line”, but it is unclear where this 
line should actually lie, especially with respect to the table padding. 
There seems to be an inconsistency since Section 6.7.3 states that “the 
first [border component], which is placed with the inside edge 
coincident with the outermost table grid boundary line, has the width of 
half the value for the ‘border-separation’ property”. And Section 6.7.10 
states that “the first [border component], which is placed with the 
outside edge coincident with the table grid boundary line, has the width 
of half the value for the border-separation trait”. Then where shall the 
padding be placed? The only consistent way to resolve this issue in my 
opinion is to make the padding coincide with the table outermost grid 
boundary line. See the attached picture as an illustration (where 
case #1 from above has been selected). It might be helpful to add an 
indication with this respect in the Recommendation.

Thanks,
Vincent Hennebert

--

-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting
Lyudmyla Novosilska | 31 Jan 2008 20:14
Favicon

ANN: RenderX announces first Beta releases of DataStyler and XML Report Generator.


RenderX, Inc., (http://www.renderx.com) is pleased to inform you about new
Beta products' availability - DataStyler 1.3.0 Beta and XML Report Generator
(XMLRG) 1.3.0 Beta are now released.

DataStyler is an application that uses Microsoft Word 2003/2007 for quick
creation of templates for variable data embedding. It is possible to pick up
data from an Oracle database and generate high-quality reports with data
merged on the fly in XML Report Generator (XMLRG).

XML Report Generator (XMLRG) is a web application that uses templates
created with Microsoft Word 2003/2007 for variable data merging from Oracle
DB 9i/10g. The application uses RenderX XEP
(http://www.renderx.com/tools/xep.html) to produce final reports in the PDF,
PostScript and AFP formats.

The main features of DataStyler are:
----------------------------------------------------------------------------
* Template design in Microsoft Word
The application uses the simple and widely-used environment of Microsoft
Word 2003-2007 for designing templates - no special editors, no programming
knowledge needed.

* Rich client interface
DataStyler is created with the rich client technology that features floating
windows, user views and perspectives, wizards, progress indicators,
workspace layout management (save/restore), automatic updates and so on.

* Data merge: filters, conditions and calculated fields The process of data
merge is of a declarative nature: It is possible to define conditions for
filters for embedded data, calculated fields (including totals and
subtotals), formatting masks, relations between different XML data fragments
(like 'one-to-one', 'one-to-many').

* Fast previewing of designed reports
Integration with the XEP rendering engine enables quick preview of the final
document in multiple output formats - PDF, PostScript, and AFP.

The main features of XML Report Generator (XMLRG) are:
----------------------------------------------------------------------------
* Web client
XMLRG uses a web interface to manage users' access to reports, data
manipulation (e.g. filtering data) and data merging process. The client side
was tested with the most popular internet browsers: Internet Explorer 6, 7;
Firefox 1.5, 2.0, Opera 8, Konqueror. The users can login from any computer
- only a web browser is needed.

* Easy deployment of the server side
The installer creates all repositories needed for the application's
successful work, including Tomcat configuration.

* Simple creation of report templates with Microsoft Word Tight integration
with DataStyler allows to design and modify report templates in the
well-known environment of Microsoft Word 2003/2007.

* Data embedding process: advanced features XMLRG allows creating not just
reports based on data stored in a databases, but also adding features like
filtering, master-details, calculated fields totals and subtotals,
formatting styles, SVG, etc.

* Multiple report output formats
XMLRG allows choosing different output formats defined by the XEP rendering
engine - PDF, Postscript, and AFP.

Developer's Kits
----------------------------------------------------------------------------

DataStyler API Beta (http://www.renderx.com/download/index.html) is a
command line utility intended to be used for data merge and reports
generation. This application uses templates created with DataStyler and XML
data source files to produce printable reports. It is a 100-percent Java
application and can be run on both Windows and Linux/Unix platforms.

XML Report Generator API (XMLRG API) Beta
(http://www.renderx.com/download/index.html) is a software library intended
for building custom report generating applications with an Oracle XML DB
backend and XEP for rendering functionality.

For more information, please visit our Web sites:
-       DataStyler: http://www.datastyler.com
-       XML Report Generator (XMLRG): http://www.xmlrg.com

Beta Versions Are Now Available
----------------------------------------------------------------------------
RenderX invites you to download XML Report Generator (XMLRG) 1.3.0 Beta and
DataStyler 1.3.0 Beta, so that you can see for yourself just how easy it is
to use the software for your needs. Please visit our Web site and try it!
http://www.renderx.com/download/index.html

Additional Information
----------------------------------------------------------------------------
* XEP XSL FO Formatter version 4.10 or later is required for PDF production.
Please refer our Web site for the system requirements of the XEP XSL FO
formatter:
http://www.renderx.com/tools/index.html

* Any browser-compatible PDF viewer is required for viewing generated PDF
documents.

Lyudmyla Novosilska,
RenderX Inc.


Gmane