Bug 44672 - Right aligned text within table cells is not correctly aligned using PCL
Summary: Right aligned text within table cells is not correctly aligned using PCL
Status: CLOSED WORKSFORME
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: pcl (show other bugs)
Version: trunk
Hardware: All All
: P2 regression
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-25 12:06 UTC by Wyatt
Modified: 2012-04-01 13:52 UTC (History)
1 user (show)



Attachments
Test file for right alignment issue (1.52 KB, text/x-xslfo)
2008-03-25 12:10 UTC, Wyatt
Details
Some demo output (made from PCL output by GhostPCL) (10.99 KB, image/tiff)
2008-03-25 13:01 UTC, Jeremias Maerki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wyatt 2008-03-25 12:06:53 UTC
Summary:
--------

When printing right aligned content in a table, the PCL renderer does not correctly align the content.  This worked in 0.20.5, but is broken in all 0.9x releases which I tested, including current trunk.  It appears that the longer the content string is, the more the output is offset to the left.  This only affects PCL; PDF output is correct.

Steps to Reproduce:
-------------------

1) Download attachment test.fo
2) Run command './fop -fo test.fo -pdf test.pdf' to get a benchmark of what the output is supposed to look like.
3) Run command './fop -fo test.fo -pcl test.pcl' to generate the incorrect output.
4) Print this file using the command 'lpr test.pcl' (this assumes that you have a default printer set up, which accepts PCL documents).

Observed Results:
-----------------

Compare the printout and the PDF file.  Note that in the PDF, the right aligned content is all aligned correctly.  In the PCL file, some of the lines are offset to the left.  It appears to me from testing that the longer the text is, the further it is offset.

Desired Results:
----------------

The PCL output should look the same as PDF: the right aligned text should truly be right aligned.

Further Notes:
--------------

I looked through the source, but was not able to find where this is handled.  If someone could give me a pointer to a few classes which may contain the bug, I would be willing to give this a shot myself.
Comment 1 Wyatt 2008-03-25 12:10:58 UTC
Created attachment 21713 [details]
Test file for right alignment issue

This is the test file which demonstrates the right alignment issue in PCL output.
Comment 2 Jeremias Maerki 2008-03-25 13:01:14 UTC
Created attachment 21714 [details]
Some demo output (made from PCL output by GhostPCL)

I can't see exactly what you described. In my tests some of the right-most characters are slightly shifted to the right and into the border I made around the table to get some boundaries. I've enhanced your example a bit and attached the resulting TIFF here. This first part uses "Helvetica" which is mapped to a PCL standard font (text-rendering set to "auto") and the second part uses a TrueType font ("DejaVu Serif") which is painted using bitmaps. You can see that in the second part there are no such effects.

The problem is the following: We don't have the exact font metrics of those native PCL fonts. They may even be different from printer to printer which would explain your different results. So the result is just an approximation for the case where a native PCL font is used. The good thing about the native font is a smaller PCL file but obviously, it comes with a downside.

Fortunately, there is a setting where you can force FOP to output all fonts using bitmaps which should make your problem go away. See the "text-rendering" setting in http://xmlgraphics.apache.org/fop/0.95/output.html#pcl-configuration
(you need to switch from "auto" to "bitmap")

The alternative would be to implement TrueType font embedding support for the PCL renderer but I've looked into this and it looks very complicated. As a side-note: Even most Windows PCL printer drivers generate all text as bitmaps rather than PCL text.

Anyway, you've asked for pointers into the code:
org.apache.fop.render.pcl.PCLRenderer, method renderText(TextArea)
The local variable "pclFont" determines whether the text is painted as PCL text or as bitmaps.

HTH
Comment 3 Wyatt 2008-03-25 13:30:39 UTC
That makes perfect sense about not knowing the font metrics for each device, and explains why we are seeing different results.  I have tried using the bitmap output, and it works perfectly.  As far as I am concerned, this is a valid workaround, and I agree with you that it would be just about impossible to get this to work for all printers without some more information.  I'm still not sure why 0.20.5 works; perhaps it defaults to bitmapped output?

I would be fine with closing this ticket as a successful workaround.  If there is nothing else which anyone wants to add, I will go ahead and do so.

Thanks again for your speedy and excellent response!

Cheers
Comment 4 Jeremias Maerki 2008-03-25 13:52:33 UTC
(In reply to comment #3)
<snip/>
> I'm still
> not sure why 0.20.5 works; perhaps it defaults to bitmapped output?

No, it always uses native PCL text. Not sure why it's good there. Maybe the lack of kerning support reduces the negative effects.

<snip/>
Comment 5 Glenn Adams 2012-04-01 13:52:17 UTC
batch transition to closed remaining pre-FOP1.0 resolved bugs