Hi Peter

Sorry for the late feedback. I don't see anything wrong with the paint
sequences you show here. These are basic painting operations. And I
assume they work perfectly when viewed in Acrobat Reader or GhostScript.

Out of experience, I can say that the PCL printer drivers of Microsoft
origin have had problems for years (not just with FOP/Acrobat but also
with MS Word and other tools). And each time the equivalent PostScript
driver was used, the problem went away (see fop-users archive, too). To
a certain degree, you can play with the driver settings. In many cases,
I saw that the PCL driver rasterizes full pages rather than using text
operator. Not sure if that's part of the problem.

In the end, I'm unclear how one should be able to find out why one
snippet below works and the other doesn't. The only real difference is
the 90° rotation in the second example. But I can't imagine that such a
basic operation should cause the problem. If it does, that driver is
simply buggy and it doesn't make sense to go through hoops to try to work
around the bug. And I can't imagine that two decimal digits more or less
will cause any such problem.

Have you tried printing the PDF from GhostScript/GhostView to the PCL
printer? Or from another PDF viewer? Does the same problem occur? Have
you tried enabling "Print as Bitmap" in Acrobat (found in the printing
dialog under "Advanced")?

On 12.11.2010 15:13:37 Peter Hancock wrote:
> Dear FOP devs,
> 
> I am working on rounded corner support in fop (see branch
> Temp_RoundedCorners for work in progress) and I have hit upon a
> problem
> whilst trying to print PDF to a printer using a PCL6 driver.
> 
> Borders in PDF are created using a graphical streams of primitive
> drawing commands and the rounded variant makes use of cubic bezier
> curves.
> I am inconsistently not able to print rounded borders and I am hoping
> a snippet of the graphical stream of two border sections may provide a
> fop developer with enough
> info to debug the problem.
> 
> The first snippet is part of PDF that is successfully transformed to
> printable PLC
>     q
>     1 0 0 1 -10 0 cm
>     4.393 4.393 m
>     7.205 1.581 11.023 0 14.999 0 c
>     383.720001 0 l
>     387.696014 0 391.514008 1.581 394.325989 4.393 c
>     387.255005 11.464 l
>     386.317993 10.527 385.045013 10 383.720001 10 c
>     15 10 l
>     13.674 10 12.401 10.527 11.464 11.464 c
>     h
>     W
>     n
>     0 G
>     [] 0 d 15 w
>     0 7.5 m 398.720001 7.5 l S
>     Q
> 
> The next snippet does not work
> 
>     q
>     1 0 0 1 51.022999 785.195007 cm
>     -0 -1 1 -0 0 0 cm
>     8.302 8.302 m
>     13.616 2.988 20.830999 0 28.344999 0 c
>     700.156982 0 l
>     707.671021 0 714.885986 2.988 720.200012 8.302 c
>     716.192017 12.31 l
>     711.940002 8.059 706.169006 5.668 700.156982 5.669 c
>     28.346001 5.669 l
>     22.333 5.669 16.562 8.059 12.31 12.31 c
>     h
>     W
>     n
>     0.85098 0.14902 0.254902 RG
>     [] 0 d 28.346001 w
>     0 14.173 m 728.502991 14.173 l S
>     Q
> 
> I am aware that the problem may be in the print driver (outside the
> scope of this list), or due to a wider context in the PDF,
> but I am consistently able to print embedded SVGs that FOP maps to
> equivalent graphical streams, and this leads me to conclude there may
> be a problem with the border generation code.
> 
> Whilst debugging this issues I did notice that the coordinates are
> formatted to 6 decimal places in the border painting yet to 8 dps in
>  org.apache.fop.svg.PDFGraphics2D ( the SVG to PDF bridge).
> Changing PDFBorderPainter to use 8 dps did not solve my problem,
> however I am wondering why the discrepancy exists.
> 
> Please prompt me for more details if you are able to offer any help
> 
> Thanks in advance,
> 
> Pete




Jeremias Maerki

Reply via email to