You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Karen Lease <kl...@club-internet.fr> on 2001/08/19 22:35:49 UTC
Re: QUERY: Why doesn't PrintRenderer use the addLine routines for
borders.
Hello Struan,
It looks as though you must have changed addLine as well to add the
border-style, since that isn't in the current version (at least not the
one I got from CVS last night.)
I'm the one responsible for changing this code in doFrame because when
borders are drawn using "lines" in PDF, it didn't seem possible to avoid
pixel errors in the segment joins. This made for ugly table borders.
It's also true that the dashed border style is the only one which could
be (at least partially) handled using the PDF line operator. Due to the
fact that we the doFrame code draws four separate lines instead of
stroking a single path, I imagine that the the dashes are not going to
work great in all cases anyway.
However I understand that you may feel something is better than nothing.
Could you submit your modified addLine code as well? We will try to come
to some satisfactory solution.
(Sorry if you'd already done this; I've been away for a few days and
might have missed an earlier message in the stack I went through last
night.)
Regards,
Karen Lease
P.S. Also, I believe the 0.20.1 version of FOP should fix the problem
you reported in late July concerning vertical alignment in table-header
rows when the table was continued. If not, please let me (fop-dev) know!
Struan Judd wrote:
>
> Instead it uses the fillRect routines.
>
> Unfortunately, I needed to have a dashed border (in PDF's) and so put back
> (well not exactly hence the query) the old ways. Which seems to work fine
> (for me).
>
> If the reason for the change was that some of the other renderers couldn't
> cope, perhaps their addLine routines could be changed to redirect to the
> fillRect ones.
>
> In any case, could the other line styles please be restored to FOP-PDF.
>
> Here is the diff of org.apache.fop.render.PrintRenderer of what I've done
> (between the '===='s):
>
> ====
> 364c364,365
> < addFilledRect(rx, ry, w, top,
> ---
> > addLine(rx, ry, rx + w, ry, top,
> > bp.getBorderStyle(BorderAndPadding.TOP),
> 365a367,369
> > // addFilledRect(rx, ry, w, top,
> > // new
> PDFColor(bp.getBorderColor(BorderAndPadding.TOP)));
> >
> 367c371,372
> < addFilledRect(rx - left, ry - h - bottom, left, h + top +
> bottom,
> ---
> > addLine(rx, ry - h, rx, ry, left,
> > bp.getBorderStyle(BorderAndPadding.LEFT),
> 368a374,376
> > // addFilledRect(rx - left, ry - h - bottom, left, h + top +
> bottom,
> > // new
> PDFColor(bp.getBorderColor(BorderAndPadding.LEFT)));
> >
> 370c378,379
> < addFilledRect(rx + w, ry - h - bottom, right, h + top +
> bottom,
> ---
> > addLine(rx + w, ry - h, rx + w, ry, right,
> > bp.getBorderStyle(BorderAndPadding.RIGHT),
> 371a381,383
> > // addFilledRect(rx + w, ry - h - bottom, right, h + top +
> bottom,
> > // new
> PDFColor(bp.getBorderColor(BorderAndPadding.RIGHT)));
> >
> 373c385,386
> < addFilledRect(rx, ry - h - bottom, w, bottom,
> ---
> > addLine(rx, ry - h, rx + w, ry - h, bottom,
> > bp.getBorderStyle(BorderAndPadding.BOTTOM),
> 374a388,389
> > // addFilledRect(rx, ry - h - bottom, w, bottom,
> > // new
> PDFColor(bp.getBorderColor(BorderAndPadding.BOTTOM)));
> ====
>
> TTFN
> ----
> Struan Judd <*> "And so it begins ..." ICQ: 4498196
> http://neongraal.sf.org.nz
> mailto:struan@sjudd.com Voicemail and Fax: +1 (201) 305-1011 x1006
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: QUERY: Why doesn't PrintRenderer use the addLine routines for
borders.
Posted by Karen Lease <kl...@club-internet.fr>.
Struan,
Oops, I hadn't noticed the second version of addLine taking the
ruleStyle since it wasn't being called in the doFrame stuff when I made
my change. Duhh.
The baseline alignment stuff is harder than the straight "after" align.
Our line-height calculations need to be right before we get into that,
so it's probably not coming up right away.
Cheers,
Karen
Struan Judd wrote:
>
> Karen,
>
> I figured that might be the reason.
>
> And yup, at the moment somthing is better than nothing.
>
> Also, Nope. No change to the addLine code was needed.
> I'm currently running the 0.20.1 release with only my patch to PrintRenderer
> as that's what we'll be deploying here so I haven't seen the current CVS but
> maybe there's been a change since then.
>
> and lastly, I haven't checked the vertical alignment issue as with what I'm
> doing display-align="after" does not achieve the align to the last baseline
> for different sized font's across table cells, (Whew!) that I needed.
>
> Thanks anyway.
>
> TTFN
> ----
> Struan Judd <*> "And so it begins ..." ICQ: 4498196
> http://neongraal.sf.org.nz
> mailto:struan@sjudd.com Voicemail and Fax: +1 (201) 305-1011 x1006
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: QUERY: Why doesn't PrintRenderer use the addLine routines for borders.
Posted by Struan Judd <st...@sjudd.com>.
Karen,
I figured that might be the reason.
And yup, at the moment somthing is better than nothing.
Also, Nope. No change to the addLine code was needed.
I'm currently running the 0.20.1 release with only my patch to PrintRenderer
as that's what we'll be deploying here so I haven't seen the current CVS but
maybe there's been a change since then.
and lastly, I haven't checked the vertical alignment issue as with what I'm
doing display-align="after" does not achieve the align to the last baseline
for different sized font's across table cells, (Whew!) that I needed.
Thanks anyway.
TTFN
----
Struan Judd <*> "And so it begins ..." ICQ: 4498196
http://neongraal.sf.org.nz
mailto:struan@sjudd.com Voicemail and Fax: +1 (201) 305-1011 x1006
> -----Original Message-----
> From: karen@front2m.grolier.fr [mailto:karen@front2m.grolier.fr]On
> Behalf Of Karen Lease
> Sent: Monday, 20 August 2001 08:36
> To: fop-dev@xml.apache.org
> Subject: Re: QUERY: Why doesn't PrintRenderer use the addLine routines
> for borders.
>
>
> Hello Struan,
>
> It looks as though you must have changed addLine as well to add the
> border-style, since that isn't in the current version (at least not the
> one I got from CVS last night.)
>
> I'm the one responsible for changing this code in doFrame because when
> borders are drawn using "lines" in PDF, it didn't seem possible to avoid
> pixel errors in the segment joins. This made for ugly table borders.
>
> It's also true that the dashed border style is the only one which could
> be (at least partially) handled using the PDF line operator. Due to the
> fact that we the doFrame code draws four separate lines instead of
> stroking a single path, I imagine that the the dashes are not going to
> work great in all cases anyway.
>
> However I understand that you may feel something is better than nothing.
> Could you submit your modified addLine code as well? We will try to come
> to some satisfactory solution.
>
> (Sorry if you'd already done this; I've been away for a few days and
> might have missed an earlier message in the stack I went through last
> night.)
>
> Regards,
> Karen Lease
>
> P.S. Also, I believe the 0.20.1 version of FOP should fix the problem
> you reported in late July concerning vertical alignment in table-header
> rows when the table was continued. If not, please let me (fop-dev) know!
>
> Struan Judd wrote:
> >
> > Instead it uses the fillRect routines.
> >
> > Unfortunately, I needed to have a dashed border (in PDF's) and
> so put back
> > (well not exactly hence the query) the old ways. Which seems to
> work fine
> > (for me).
> >
> > If the reason for the change was that some of the other
> renderers couldn't
> > cope, perhaps their addLine routines could be changed to redirect to the
> > fillRect ones.
> >
> > In any case, could the other line styles please be restored to FOP-PDF.
> >
> > Here is the diff of org.apache.fop.render.PrintRenderer of what
> I've done
> > (between the '===='s):
> >
> > ====
> > 364c364,365
> > < addFilledRect(rx, ry, w, top,
> > ---
> > > addLine(rx, ry, rx + w, ry, top,
> > > bp.getBorderStyle(BorderAndPadding.TOP),
> > 365a367,369
> > > // addFilledRect(rx, ry, w, top,
> > > // new
> > PDFColor(bp.getBorderColor(BorderAndPadding.TOP)));
> > >
> > 367c371,372
> > < addFilledRect(rx - left, ry - h - bottom, left, h + top +
> > bottom,
> > ---
> > > addLine(rx, ry - h, rx, ry, left,
> > > bp.getBorderStyle(BorderAndPadding.LEFT),
> > 368a374,376
> > > // addFilledRect(rx - left, ry - h - bottom,
> left, h + top +
> > bottom,
> > > // new
> > PDFColor(bp.getBorderColor(BorderAndPadding.LEFT)));
> > >
> > 370c378,379
> > < addFilledRect(rx + w, ry - h - bottom, right, h + top +
> > bottom,
> > ---
> > > addLine(rx + w, ry - h, rx + w, ry, right,
> > > bp.getBorderStyle(BorderAndPadding.RIGHT),
> > 371a381,383
> > > // addFilledRect(rx + w, ry - h - bottom, right, h + top +
> > bottom,
> > > // new
> > PDFColor(bp.getBorderColor(BorderAndPadding.RIGHT)));
> > >
> > 373c385,386
> > < addFilledRect(rx, ry - h - bottom, w, bottom,
> > ---
> > > addLine(rx, ry - h, rx + w, ry - h, bottom,
> > > bp.getBorderStyle(BorderAndPadding.BOTTOM),
> > 374a388,389
> > > // addFilledRect(rx, ry - h - bottom, w, bottom,
> > > // new
> > PDFColor(bp.getBorderColor(BorderAndPadding.BOTTOM)));
> > ====
> >
> > TTFN
> > ----
> > Struan Judd <*> "And so it begins ..." ICQ: 4498196
> > http://neongraal.sf.org.nz
> > mailto:struan@sjudd.com Voicemail and Fax: +1
> (201) 305-1011 x1006
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> > For additional commands, email: fop-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org