xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Art Welch <ar...@EASTPOINT.COM>
Subject RE: Commits please
Date Fri, 23 Mar 2001 22:28:59 GMT
It didn't but now does - or something like that. Anyway, now the PCLRenderer
does the same as the PDFRenderer.

We may need to do something more sophisticated at some point. Can a PDF/PS
path do the borders if we had something like a solid thick red top, dashed
green thin right side, dotted blue thin bottom, and no left side? I used to
do some PostScript programming about 10 years ago, but can not remember...
In any event I would think that we would still be better keeping doFrame()
common and adding an addPath() method for the renderer's to implement. This
would be a bit challenging for some renderers (like PCL), because they would
need to handle the path details in the renderer. PCL for example has very
little graphic support of it's own, basically all it knows to draw on it's
own is a rectangle (which may be filled with one of the standard fills).
Just to support lines that are not horizontal or vertical I had to do a bit
of work in the PCLSVGRenderer (circles, etc were even more fun). If someone
wants to figure out how to do paths for PDF, I can try to figure out how to
do it in PCL Of course short term addPath() in PCLRenderer could be
implemented as calls to addLine().

I am not sure that this is much of a priority though. With the latest
changes it is basically correct, there are just some minor cosmetic details.
But on the other hand, this could be fun to fix...

Art

-----Original Message-----
From: Karen Lease [mailto:klease@club-internet.fr]
Sent: Friday, March 23, 2001 4:34 PM
To: fop-dev@xml.apache.org
Subject: Re: Commits please


OK, Art, I committed the PrintRenderer.
So I guess PCL doesn't center the stroke on the line coordinates like
PDF does.

If we have several lines to draw in PDF which share endpoints (like the
frame case), we could get the pdf renderer to do the work of correctly
managing the line joins. But then we couldn't use the simple addLine
method; we'd have to make a path and stroke it. I don't know if that's
possible with other renderers. Of course, PDFRenderer could specialize
doFrame...

Karen

Art Welch wrote:
> 
> Actually the fix to PCLRenderer corrected it so that it was behaving
> identically to the PDFRenderer (so it is still needed). The change to
> PrintRenderer.doFrame() should now make both of them correct (except for
the
> quantization error). Because the problem with doFrame() had to do with the
> line thickness, thin borders did not appear to have a problem. When
borders
> had thick lines, you could see that the borders were not being drawn
> correctly.
> 
> Thank You,
> Art
> 
> -----Original Message-----
> From: Karen Lease [mailto:klease@club-internet.fr]
> Sent: Thursday, March 22, 2001 5:40 PM
> To: fop-dev@xml.apache.org
> Subject: Re: Commits please
> 
> Art,
> 
> Thanks for the doFrame fix, which I am preparing to commit. (The
> TXTRenderer is done.)  But since you are now correcting for the line
> width in PrintRenderer.doFrame, shouldn't we get rid of the corrections
> in PCLRenderer.addLine() that I committed for you last week? Otherwise
> it seems like PCL will be overcorrecting.
> 
> Karen
>

---------------------------------------------------------------------
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


Mime
View raw message