You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Jerven Bolleman <me...@jerven.eu> on 2007/12/14 16:22:43 UTC

Re: fo:table border thickness

Dear Fop Users and Developers,

First of all, thank you for all your effort in providing fantastic
software that really helps people.

I am having similar problem as the original writer.

Unfortunately, we were migrating from Fop 0.20.5 to 0.9*. And one of
our major reports is no longer working the way we expected.

Basically lines sometimes disappear between colored (gray)
table-cells. This did not happen when using fop 0.20 to generate the
pdf.
While the observation is true that the lines have the correct width
(seen once zooming in or printing), they are no longer drawn by adobe
acrobat.

I can send the xslt on request as they are 143 pages of style sheet.
But I have a minimal sample. Attached, if there is interest in the
resulting
pdf's in 0.20 and 0.94 then I am happy to provide them.

The workaround using border-collapse="separate" provides even more
problems in adobe.

The specific version is 0.94 for FOP and 7.0.8 for acrobat reader on
Windows. Although it also occurs with the free Sumatra gpl viewer.

Does anyone have any ideas?

Jerven


-- 
Jerven Bolleman
me@jerven.eu

Re: fo:table border thickness

Posted by Jerven Bolleman <me...@jerven.eu>.
Ok, thanks for the tips. I will try to help constructively.

Jerven

On 12/17/07, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> On 17.12.2007 13:12:33 Jerven Bolleman wrote:
> > Hi,
> >
> > Are you sure? as the same effect does not seem to occur when using the
> > seperate option on border-collapse.
>
> Yes. The border painting code is the same for both cases.
>
> > See the attached bug.xsl and compare with the previous one. In the new
> > case there are 2 separate lines 0.1mm each while in the original
> > sample there where collapsed lines 0.2 mm wide.
>
> Please look into the PDF 1.4 specification, chapter 6.5.4. It has an
> illustration with some text that might help you understand why this
> happens. It's not always the absolute, specified width of the line that
> decides whether a line will be 0, 1 or 2 pixels wide on the target
> device (i.e. the screen or printer). It also depends on the position of
> the line in the target device's pixel grid. That's why they sometimes
> appear and sometimes they don't.
>
> See also PDF 1.4, chapter 4.3.1, scroll down to "Line Width".
>
> > I am now using the separate work arround as it will solve my problem.
> > Although now I get to eddit some 300 pages of xslt to solve the side
> > effects of the border width changes. Got to love legacy enterprise
> > software :D
> >
> > I will still spend some time looking into the fop code, but this
> > weekend showed that might be above my skill level ;)
>
> If you do dive into this, starting looking in PDFRenderer.java, method
> drawBorderLine().
>
> > Thanks,
> > Jerven
> >
> > On 12/17/07, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> > > No, that's not the problem. The cell background is painted and then cell
> > > borders are painted next (i.e. "over" them). The problem is rather
> > > subpixel effects. Lines can become smaller than one device pixel and can
> > > therefore disappear (worst case). At any rate, FOP makes the lines
> > > exactly as wide as you specify them. The negative effect occurs at
> > > rendering time in the viewer.
> > >
> > > I went looking into the PDF spec again (the general topic has come up
> > > before) and this time I found something. There's chapter 6.5.4
> > > "Automatic Stroke Adjustment" (in PDF 1.4) which could be used to
> > > help counteract such effects. Maybe someone wants to experiment with the
> > > "SA" state entry. Patches are welcome.
> > >
> > > On 14.12.2007 17:16:10 Pascal Sancho wrote:
> > > > Hi,
> > > >
> > > > After some checks, this happens because cells borders are drawn before cells background.
> > > > As a workaround, you can use the background-color property on deeper table element (from fo:table to fo:table-row).
> > > >
> > > > HTH,
> > > >
> > > > Pascal
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Jerven Bolleman [mailto:me@jerven.eu]
> > > > > Envoyé : vendredi 14 décembre 2007 16:23
> > > > > À : fop-users@xmlgraphics.apache.org
> > > > > Objet : Re: fo:table border thickness
> > > > >
> > > > > Dear Fop Users and Developers,
> > > > >
> > > > > First of all, thank you for all your effort in providing fantastic
> > > > > software that really helps people.
> > > > >
> > > > > I am having similar problem as the original writer.
> > > > >
> > > > > Unfortunately, we were migrating from Fop 0.20.5 to 0.9*. And one of
> > > > > our major reports is no longer working the way we expected.
> > > > >
> > > > > Basically lines sometimes disappear between colored (gray)
> > > > > table-cells. This did not happen when using fop 0.20 to generate the
> > > > > pdf.
> > > > > While the observation is true that the lines have the correct width
> > > > > (seen once zooming in or printing), they are no longer drawn by adobe
> > > > > acrobat.
> > > > >
> > > > > I can send the xslt on request as they are 143 pages of style sheet.
> > > > > But I have a minimal sample. Attached, if there is interest in the
> > > > > resulting
> > > > > pdf's in 0.20 and 0.94 then I am happy to provide them.
> > > > >
> > > > > The workaround using border-collapse="separate" provides even more
> > > > > problems in adobe.
> > > > >
> > > > > The specific version is 0.94 for FOP and 7.0.8 for acrobat reader on
> > > > > Windows. Although it also occurs with the free Sumatra gpl viewer.
> > > > >
> > > > > Does anyone have any ideas?
> > > > >
> > > > > Jerven
> > > > >
> > > > >
> > > > > --
> > > > > Jerven Bolleman
> > > > > me@jerven.eu
> > >
> > >
> > > Jeremias Maerki
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> > >
> > >
> >
> >
> > --
> > Jerven Bolleman
> > me@jerven.eu
>
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>


-- 
Jerven Bolleman
me@jerven.eu

Re: fo:table border thickness

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 17.12.2007 13:12:33 Jerven Bolleman wrote:
> Hi,
> 
> Are you sure? as the same effect does not seem to occur when using the
> seperate option on border-collapse.

Yes. The border painting code is the same for both cases.

> See the attached bug.xsl and compare with the previous one. In the new
> case there are 2 separate lines 0.1mm each while in the original
> sample there where collapsed lines 0.2 mm wide.

Please look into the PDF 1.4 specification, chapter 6.5.4. It has an
illustration with some text that might help you understand why this
happens. It's not always the absolute, specified width of the line that
decides whether a line will be 0, 1 or 2 pixels wide on the target
device (i.e. the screen or printer). It also depends on the position of
the line in the target device's pixel grid. That's why they sometimes
appear and sometimes they don't.

See also PDF 1.4, chapter 4.3.1, scroll down to "Line Width".

> I am now using the separate work arround as it will solve my problem.
> Although now I get to eddit some 300 pages of xslt to solve the side
> effects of the border width changes. Got to love legacy enterprise
> software :D
> 
> I will still spend some time looking into the fop code, but this
> weekend showed that might be above my skill level ;)

If you do dive into this, starting looking in PDFRenderer.java, method
drawBorderLine().

> Thanks,
> Jerven
> 
> On 12/17/07, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> > No, that's not the problem. The cell background is painted and then cell
> > borders are painted next (i.e. "over" them). The problem is rather
> > subpixel effects. Lines can become smaller than one device pixel and can
> > therefore disappear (worst case). At any rate, FOP makes the lines
> > exactly as wide as you specify them. The negative effect occurs at
> > rendering time in the viewer.
> >
> > I went looking into the PDF spec again (the general topic has come up
> > before) and this time I found something. There's chapter 6.5.4
> > "Automatic Stroke Adjustment" (in PDF 1.4) which could be used to
> > help counteract such effects. Maybe someone wants to experiment with the
> > "SA" state entry. Patches are welcome.
> >
> > On 14.12.2007 17:16:10 Pascal Sancho wrote:
> > > Hi,
> > >
> > > After some checks, this happens because cells borders are drawn before cells background.
> > > As a workaround, you can use the background-color property on deeper table element (from fo:table to fo:table-row).
> > >
> > > HTH,
> > >
> > > Pascal
> > >
> > > > -----Message d'origine-----
> > > > De : Jerven Bolleman [mailto:me@jerven.eu]
> > > > Envoyé : vendredi 14 décembre 2007 16:23
> > > > À : fop-users@xmlgraphics.apache.org
> > > > Objet : Re: fo:table border thickness
> > > >
> > > > Dear Fop Users and Developers,
> > > >
> > > > First of all, thank you for all your effort in providing fantastic
> > > > software that really helps people.
> > > >
> > > > I am having similar problem as the original writer.
> > > >
> > > > Unfortunately, we were migrating from Fop 0.20.5 to 0.9*. And one of
> > > > our major reports is no longer working the way we expected.
> > > >
> > > > Basically lines sometimes disappear between colored (gray)
> > > > table-cells. This did not happen when using fop 0.20 to generate the
> > > > pdf.
> > > > While the observation is true that the lines have the correct width
> > > > (seen once zooming in or printing), they are no longer drawn by adobe
> > > > acrobat.
> > > >
> > > > I can send the xslt on request as they are 143 pages of style sheet.
> > > > But I have a minimal sample. Attached, if there is interest in the
> > > > resulting
> > > > pdf's in 0.20 and 0.94 then I am happy to provide them.
> > > >
> > > > The workaround using border-collapse="separate" provides even more
> > > > problems in adobe.
> > > >
> > > > The specific version is 0.94 for FOP and 7.0.8 for acrobat reader on
> > > > Windows. Although it also occurs with the free Sumatra gpl viewer.
> > > >
> > > > Does anyone have any ideas?
> > > >
> > > > Jerven
> > > >
> > > >
> > > > --
> > > > Jerven Bolleman
> > > > me@jerven.eu
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
> >
> 
> 
> -- 
> Jerven Bolleman
> me@jerven.eu




Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: fo:table border thickness

Posted by Jerven Bolleman <me...@jerven.eu>.
Hi,

Are you sure? as the same effect does not seem to occur when using the
seperate option on border-collapse.

See the attached bug.xsl and compare with the previous one. In the new
case there are 2 separate lines 0.1mm each while in the original
sample there where collapsed lines 0.2 mm wide.

I am now using the separate work arround as it will solve my problem.
Although now I get to eddit some 300 pages of xslt to solve the side
effects of the border width changes. Got to love legacy enterprise
software :D

I will still spend some time looking into the fop code, but this
weekend showed that might be above my skill level ;)

Thanks,
Jerven

On 12/17/07, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> No, that's not the problem. The cell background is painted and then cell
> borders are painted next (i.e. "over" them). The problem is rather
> subpixel effects. Lines can become smaller than one device pixel and can
> therefore disappear (worst case). At any rate, FOP makes the lines
> exactly as wide as you specify them. The negative effect occurs at
> rendering time in the viewer.
>
> I went looking into the PDF spec again (the general topic has come up
> before) and this time I found something. There's chapter 6.5.4
> "Automatic Stroke Adjustment" (in PDF 1.4) which could be used to
> help counteract such effects. Maybe someone wants to experiment with the
> "SA" state entry. Patches are welcome.
>
> On 14.12.2007 17:16:10 Pascal Sancho wrote:
> > Hi,
> >
> > After some checks, this happens because cells borders are drawn before cells background.
> > As a workaround, you can use the background-color property on deeper table element (from fo:table to fo:table-row).
> >
> > HTH,
> >
> > Pascal
> >
> > > -----Message d'origine-----
> > > De : Jerven Bolleman [mailto:me@jerven.eu]
> > > Envoyé : vendredi 14 décembre 2007 16:23
> > > À : fop-users@xmlgraphics.apache.org
> > > Objet : Re: fo:table border thickness
> > >
> > > Dear Fop Users and Developers,
> > >
> > > First of all, thank you for all your effort in providing fantastic
> > > software that really helps people.
> > >
> > > I am having similar problem as the original writer.
> > >
> > > Unfortunately, we were migrating from Fop 0.20.5 to 0.9*. And one of
> > > our major reports is no longer working the way we expected.
> > >
> > > Basically lines sometimes disappear between colored (gray)
> > > table-cells. This did not happen when using fop 0.20 to generate the
> > > pdf.
> > > While the observation is true that the lines have the correct width
> > > (seen once zooming in or printing), they are no longer drawn by adobe
> > > acrobat.
> > >
> > > I can send the xslt on request as they are 143 pages of style sheet.
> > > But I have a minimal sample. Attached, if there is interest in the
> > > resulting
> > > pdf's in 0.20 and 0.94 then I am happy to provide them.
> > >
> > > The workaround using border-collapse="separate" provides even more
> > > problems in adobe.
> > >
> > > The specific version is 0.94 for FOP and 7.0.8 for acrobat reader on
> > > Windows. Although it also occurs with the free Sumatra gpl viewer.
> > >
> > > Does anyone have any ideas?
> > >
> > > Jerven
> > >
> > >
> > > --
> > > Jerven Bolleman
> > > me@jerven.eu
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>


-- 
Jerven Bolleman
me@jerven.eu

Re: fo:table border thickness

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
No, that's not the problem. The cell background is painted and then cell
borders are painted next (i.e. "over" them). The problem is rather
subpixel effects. Lines can become smaller than one device pixel and can
therefore disappear (worst case). At any rate, FOP makes the lines
exactly as wide as you specify them. The negative effect occurs at
rendering time in the viewer.

I went looking into the PDF spec again (the general topic has come up
before) and this time I found something. There's chapter 6.5.4
"Automatic Stroke Adjustment" (in PDF 1.4) which could be used to
help counteract such effects. Maybe someone wants to experiment with the
"SA" state entry. Patches are welcome.

On 14.12.2007 17:16:10 Pascal Sancho wrote:
> Hi,
> 
> After some checks, this happens because cells borders are drawn before cells background.
> As a workaround, you can use the background-color property on deeper table element (from fo:table to fo:table-row).
> 
> HTH,
> 
> Pascal
> 
> > -----Message d'origine-----
> > De : Jerven Bolleman [mailto:me@jerven.eu] 
> > Envoyé : vendredi 14 décembre 2007 16:23
> > À : fop-users@xmlgraphics.apache.org
> > Objet : Re: fo:table border thickness
> > 
> > Dear Fop Users and Developers,
> > 
> > First of all, thank you for all your effort in providing fantastic
> > software that really helps people.
> > 
> > I am having similar problem as the original writer.
> > 
> > Unfortunately, we were migrating from Fop 0.20.5 to 0.9*. And one of
> > our major reports is no longer working the way we expected.
> > 
> > Basically lines sometimes disappear between colored (gray)
> > table-cells. This did not happen when using fop 0.20 to generate the
> > pdf.
> > While the observation is true that the lines have the correct width
> > (seen once zooming in or printing), they are no longer drawn by adobe
> > acrobat.
> > 
> > I can send the xslt on request as they are 143 pages of style sheet.
> > But I have a minimal sample. Attached, if there is interest in the
> > resulting
> > pdf's in 0.20 and 0.94 then I am happy to provide them.
> > 
> > The workaround using border-collapse="separate" provides even more
> > problems in adobe.
> > 
> > The specific version is 0.94 for FOP and 7.0.8 for acrobat reader on
> > Windows. Although it also occurs with the free Sumatra gpl viewer.
> > 
> > Does anyone have any ideas?
> > 
> > Jerven
> > 
> > 
> > -- 
> > Jerven Bolleman
> > me@jerven.eu


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org