You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Tres Finocchiaro <tr...@gmail.com> on 2023/10/18 01:02:22 UTC
Slight rendering issues Apache FOP document
Hi,
I have a document (USPS shipping label) that was created using (what I
believe to be Apache FOP) here:
https://github.com/qzind/tray/files/12458435/Public-Test-Label.pdf
Preview's inspector says:
> "Apache FOP Version 2.3; modified using iText® 5.5.6 ©2000-2015 iText
> Group NV"
- When it's previewed in Previewer (MacOS), Chrome, Adobe Acrobat the
outermost line/stroke is clearly viewable and easy to see.
- When it's previewed in PDFDebugger, the top and bottom of the
outermost line/stroke is missing.
- When I print this document to a PDF printer on MacOS using rendering
hint VALUE_STROKE_PURE, the top and bottom of this outermost line/stroke
appear, but the right is cut off. (antialiasing hints on/off do not seem to
impact this)
Is the rendering of the outermost line/stroke simply a quirk to using
PDFBOX, or is there a rendering issue?
- Tres.Finocchiaro@gmail.com
Re: Slight rendering issues Apache FOP document
Posted by Tilman Hausherr <TH...@t-online.de>.
On 14.11.2023 18:46, Tres Finocchiaro wrote:
>>> It's mostly in PageDrawer.java search for things line width and clip.
>
> Attempts to affect the line width are ineffective.
>
> For example, there's a function in PagDrawer which ensures that the
> threshold for lineWidth is at least 0.25. I've changed this to 2.0f, 10.0f
> and no perceivable differences. Most of the lines are reporting as *0.708f*,
> but I'm unsure how to know if they represent the lines in question.
>
> // minimum line width as used by Adobe Reader
> - if (lineWidth < 0.25)
> + if (lineWidth < 10)
> {
> - lineWidth = 0.25f;
> + lineWidth = 10f;
> }
> Per suggestion, I've looked into references to clip as well, but I can't
> find any obvious areas to change, most of them seem to be slight bugfixes
> or direct passing to the Graphics object. I was unable to find a way to
> modify the PDF behavior using clip.
>
> Do you have any other pointers to how to modify the behavior of this PDF?
The problem is what can be shown after clipping, and these decisions /
calculations are done in java itself.
Tilman
>
> I understand that the issue is likely in the native JVM. components, but I
> was hoping to at least impact the behavior through code changes to better
> understand the problem.
>
>
> -Tres
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
>
> Even if this is a Java bug, being able to detect which PDFs suffer from it
> would be helpful. At least then you could warn users instead of them
> running into silent failures.
I don't yet know how to detect this issue, but since the producer of the
PDF -- PitneyShip -- could end up sending other similarly created PDFs to
other Java apps, simply knowing that the problem exists is often half the
battle.
At time of writing this, I have not yet made an attempt to reach out to the
PDF authors (I don't directly use this service). The fact that it only
affects MacOS is likely why it's gone so long undetected. In the case of
the company/person that reported this, they had been
unknowingly/accidentally rasterizing the PDF up until discovery, so there's
at least a viable workaround.
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
>
> This isn't a PDFBox bug.
The fact that this only occurs on MacOS reminds me quite a bit of
PDFBOX-4709, where Windows would suffer quality issues at certain DPIs
(probably best illustrated visually here:
https://github.com/adoptium/adoptium-support/issues/45#issuecomment-655696251
).
PDFBOX-4709 did result in a JVM fix: JDK-8256264. Unfortunately PDFBOX 2.0
wasn't able to take advantage of this fix, but PDFBOX 1.8 was.
If the bug cannot be fixed in the PDFBOX source as @Tilman Hausherr
<TH...@t-online.de> predicts, I hope that it's still welcome to be
tracked there until we can isolate the JVM component that causes the
problem.
-Tres
- Tres.Finocchiaro@gmail.com
On Sun, Nov 12, 2023 at 7:42 AM CowwoC <co...@gmail.com> wrote:
> Even if this is a Java bug, being able to detect which PDFs suffer from it
> would be helpful. At least then you could warn users instead of them
> running into silent failures.
>
> Gili
>
> On Sun, Nov 12, 2023, 03:17 Tilman Hausherr <TH...@t-online.de> wrote:
>
> > On 11.11.2023 15:50, Tilman Hausherr wrote:
> > >>
> > >> Should this be enough for a bug report?
> > >>
> > > I don't know if they'll bother with a file that needs the PDFBox
> > > viewer, they'll claim that we're at fault.
> >
> > When I wrote "they" I meant the java folks. This isn't a PDFBox bug.
> >
> > Tilman
> >
>
Re: Slight rendering issues Apache FOP document
Posted by CowwoC <co...@gmail.com>.
Even if this is a Java bug, being able to detect which PDFs suffer from it
would be helpful. At least then you could warn users instead of them
running into silent failures.
Gili
On Sun, Nov 12, 2023, 03:17 Tilman Hausherr <TH...@t-online.de> wrote:
> On 11.11.2023 15:50, Tilman Hausherr wrote:
> >>
> >> Should this be enough for a bug report?
> >>
> > I don't know if they'll bother with a file that needs the PDFBox
> > viewer, they'll claim that we're at fault.
>
> When I wrote "they" I meant the java folks. This isn't a PDFBox bug.
>
> Tilman
>
Re: Slight rendering issues Apache FOP document
Posted by Tilman Hausherr <TH...@t-online.de>.
On 11.11.2023 15:50, Tilman Hausherr wrote:
>>
>> Should this be enough for a bug report?
>>
> I don't know if they'll bother with a file that needs the PDFBox
> viewer, they'll claim that we're at fault.
When I wrote "they" I meant the java folks. This isn't a PDFBox bug.
Tilman
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
>
> > It's mostly in PageDrawer.java search for things line width and clip.
Attempts to affect the line width are ineffective.
For example, there's a function in PagDrawer which ensures that the
threshold for lineWidth is at least 0.25. I've changed this to 2.0f, 10.0f
and no perceivable differences. Most of the lines are reporting as *0.708f*,
but I'm unsure how to know if they represent the lines in question.
// minimum line width as used by Adobe Reader
- if (lineWidth < 0.25)
+ if (lineWidth < 10)
{
- lineWidth = 0.25f;
+ lineWidth = 10f;
}
Per suggestion, I've looked into references to clip as well, but I can't
find any obvious areas to change, most of them seem to be slight bugfixes
or direct passing to the Graphics object. I was unable to find a way to
modify the PDF behavior using clip.
Do you have any other pointers to how to modify the behavior of this PDF?
I understand that the issue is likely in the native JVM. components, but I
was hoping to at least impact the behavior through code changes to better
understand the problem.
-Tres
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
>
>
> https://drive.google.com/file/d/1E3Q9JlywRFyKJ7rSwL9rQNEGdbmvDbgc/view?usp=sharing
>
> This is an improved file with a rectangular clipping. The trapezoidal
> form is not relevant IMHO.
>
I forgot to mention that this file didn't reproduce the printing issues in
my testing, which is why the public bug report uses FOP libraries directly.
https://issues.apache.org/jira/browse/PDFBOX-5715
I understand that this issue is unlikely to be related to FOP specifically,
but I included it in the maven project because it offers some control over
the PDF content, which may be helpful when trying to isolate the issue.
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
Thanks for the document, I'll do some testing.
This isn't a viewer issue though, we need to move from that :D
These lines are missing when printing to a 203 DPI printer on MacOS but
they're rather randomly missing (some render, some do not).
Forcing rasterization fixes it.
Since a reproducible example will greatly help track this down, I'll do
some more testing and submit a proper bug report with exact steps to
reproduce.
Thanks so far for all the help.
-Tres
- Tres.Finocchiaro@gmail.com
On Sat, Nov 11, 2023 at 9:50 AM Tilman Hausherr <TH...@t-online.de>
wrote:
> On 09.11.2023 22:30, Tres Finocchiaro wrote:
> > I can reproduce with an example provided with Apache FOP:
> >
> > ./fop -fo examples/fo/basic/border.fo -pdf foo.pdf
> >
> >
> > It seems to use the same trapezoidal vector borders as the originating
> > PDF. When printing to a 4x6 label printer, some of the borders
> disappear.
> >
> > Should this be enough for a bug report?
> >
> I don't know if they'll bother with a file that needs the PDFBox viewer,
> they'll claim that we're at fault. I'm not even sure it's a bug. The
> clipped area is smaller than 1 pixel. Other viewers show it because they
> render at more than 100%.
>
>
> https://drive.google.com/file/d/1E3Q9JlywRFyKJ7rSwL9rQNEGdbmvDbgc/view?usp=sharing
>
> This is an improved file with a rectangular clipping. The trapezoidal
> form is not relevant IMHO.
>
> Tilman
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
Re: Slight rendering issues Apache FOP document
Posted by Tilman Hausherr <TH...@t-online.de>.
On 09.11.2023 22:30, Tres Finocchiaro wrote:
> I can reproduce with an example provided with Apache FOP:
>
> ./fop -fo examples/fo/basic/border.fo -pdf foo.pdf
>
>
> It seems to use the same trapezoidal vector borders as the originating
> PDF. When printing to a 4x6 label printer, some of the borders disappear.
>
> Should this be enough for a bug report?
>
I don't know if they'll bother with a file that needs the PDFBox viewer,
they'll claim that we're at fault. I'm not even sure it's a bug. The
clipped area is smaller than 1 pixel. Other viewers show it because they
render at more than 100%.
https://drive.google.com/file/d/1E3Q9JlywRFyKJ7rSwL9rQNEGdbmvDbgc/view?usp=sharing
This is an improved file with a rectangular clipping. The trapezoidal
form is not relevant IMHO.
Tilman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
... also, replacing the border-width="0.5mm" with "1mm" everywhere in the
FO file is a viable workaround.
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
I can reproduce with an example provided with Apache FOP:
./fop -fo examples/fo/basic/border.fo -pdf foo.pdf
It seems to use the same trapezoidal vector borders as the originating
PDF. When printing to a 4x6 label printer, some of the borders disappear.
Should this be enough for a bug report?
Re: Slight rendering issues Apache FOP document
Posted by Tilman Hausherr <TH...@t-online.de>.
Hi,
I was able to reduce it further:
https://drive.google.com/file/d/1la-XYjKpDKar8sb9lUI1FTuxNutq682W/view?usp=sharing
The effect with PDFDebugger still happens. Nothing at 100%, line at 150%.
The content stream is now this:
1 0 0 1 7.812 413.676 cm
0 0 m
-0.354 -0.354 l
56.693 -0.354 l
56.693 0 l
55.913 0.354 l
0.354 0.354 l
h
W
n
1 0 0 1 -0.354 0 cm
0.708 w
0 0 m
57.047 0 l
S
From what I see, there is a clipping with width 0.708 and a line with
the same width, but at 100% it isn't shown.
The next thing to do would be to check whether these numbers are passed
1:1 to PageDrawer or if the numbers change.
If they don't change, then it means that Java doesn't display this
because the line (and the clipping "rectangle") is smaller than 1 pixel.
Tilman
On 01.11.2023 18:44, Tres Finocchiaro wrote:
>> It's mostly in PageDrawer.java search for things line width and clip.
>
> I attempted to make some modifications to PageDrawer, but couldn't figure
> out any changed that improved the behavior.
>
> Also convert the PDF to uncompressed and try to change the page content
>> stream so that only the lines remain, i.e. try to get a "reduced" PDF that
>> still produces the effect.
>
> The original PDF was encrypted, so this was impossible, but Pitney Bowes
> was kind enough to send over an unencrypted PDF. Since I do not know the
> PDF format very well, I'm a bit unsure how to make sure it's uncompressed.
> Using Acrobat Pro, I was able to remove many of the components of the PDF
> while still reproducing the issue. If I remove too many of them, Acrobat
> turns the PDF into an image, so this "reduced" PDF still has many items
> which can be removed to narrow this down.
>
> https://github.com/qzind/tray/files/13229981/pitney_bowes_simplified.pdf
>
> This new PDF is interesting because a similar issue with vanishing lines
> occurs on the box around the C005 text, which makes me believe the issue
> will be even easier to narrow down.
>
> Another detail that I find interesting is how these lines render in Adobe
> Acrobat. For example, when I stretch the line to be larger, it looks very
> odd. I've taken a screenshot from Acrobat to illustrate this:
>
> https://user-images.githubusercontent.com/6345473/279754645-d406b70f-5ff1-430f-88ba-868efdf79973.png
>
>
> ... Furthermore, resizing of this line nearly deadlocks Acrobat on my
> computer. I'm not a regular user of Acrobat, so this may be irrelevant,
> but it seemed odd that a trivial resize operation on a document with a
> single line would be so taxing.
>
> Is the PDF now in a better format for debugging? If not, what can be done
> to help narrow down this cause?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
>
> It's mostly in PageDrawer.java search for things line width and clip.
I attempted to make some modifications to PageDrawer, but couldn't figure
out any changed that improved the behavior.
Also convert the PDF to uncompressed and try to change the page content
> stream so that only the lines remain, i.e. try to get a "reduced" PDF that
> still produces the effect.
The original PDF was encrypted, so this was impossible, but Pitney Bowes
was kind enough to send over an unencrypted PDF. Since I do not know the
PDF format very well, I'm a bit unsure how to make sure it's uncompressed.
Using Acrobat Pro, I was able to remove many of the components of the PDF
while still reproducing the issue. If I remove too many of them, Acrobat
turns the PDF into an image, so this "reduced" PDF still has many items
which can be removed to narrow this down.
https://github.com/qzind/tray/files/13229981/pitney_bowes_simplified.pdf
This new PDF is interesting because a similar issue with vanishing lines
occurs on the box around the C005 text, which makes me believe the issue
will be even easier to narrow down.
Another detail that I find interesting is how these lines render in Adobe
Acrobat. For example, when I stretch the line to be larger, it looks very
odd. I've taken a screenshot from Acrobat to illustrate this:
https://user-images.githubusercontent.com/6345473/279754645-d406b70f-5ff1-430f-88ba-868efdf79973.png
... Furthermore, resizing of this line nearly deadlocks Acrobat on my
computer. I'm not a regular user of Acrobat, so this may be irrelevant,
but it seemed odd that a trivial resize operation on a document with a
single line would be so taxing.
Is the PDF now in a better format for debugging? If not, what can be done
to help narrow down this cause?
Re: Slight rendering issues Apache FOP document
Posted by Tilman Hausherr <TH...@t-online.de>.
Hi,
It's mostly in PageDrawer.java
search for things line width and clip.
Also convert the PDF to uncompressed and try to change the page content
stream so that only the lines remain, i.e. try to get a "reduced" PDF
that still produces the effect.
Tilman
On 19.10.2023 06:28, Tres Finocchiaro wrote:
> Hi,
>
> Your initial complaint was about PDFDebugger
>
>
> PDFDebugger was mentioned because the top and bottom cut off symptom was
> visible there as well as the PDFwriter.
>
> The original symptom we observed was that the right side of the bordering
> box on the PDF is cut off. This right side is only cut off when rendering
> hints are set to VALUE_STROKE_PURE, otherwise the top and bottom are cut
> off.
>
> It was my initial assumption that the two symptoms are related, which is
> why I mentioned PDFDebugger.
>
> What I don't understand about the DPI comments is that I'm never actually
> printing to a 72 dpi printer, so I would not expect the 72 dpi to be an
> issue, but I still do not understand this concept in the PDF. I've used a
> few tools to attempt to inspect the DPI of this document and I cannot find
> an application that will report this information. Historically when
> printing, I supply a density of zero, which seems to result in the best
> print quality.
>
> The PDF is likely fine. The bug is either with PDFBox or with Java itself.
>> My suspicion is that it's a rounding error.
>
> I feel that this statement slightly contradicts the statements about the 72
> dpi being too low, hence my confusion. Regardless, where's the best place
> to start looking in the codebase for this problem? For example, there are
> some other artifacts as well, which may be related.
>
> The problem is much more noticable using the CUPS PDF printer on Mac, but
> even on Windows, there are some slight positioning and alignment
> differences.
>
> https://github.com/qzind/tray/assets/6345473/3022d304-1994-45bb-9907-b28a6692a8dc
>
> I remember from working with PDFBOX on PDFBOX-4709 that some draw routines
> lose precision at low printer DPIs, but this seems to be the opposite where
> the document's DPI is low and causes the issue regardless of the printer's
> DPI.
>
> To prove that it is a jdk bug would require a lot of work, and even then
>> it's unlikely it would be fixed
>
> We sponsored this fix https://github.com/openjdk/jdk/pull/1183 so I'm
> optimistic that if the issue is fixable that openjdk would be receptive to
> a fix.
>
> So if we're to isolate this issue simply to the right hand side missing
> when VALUE_STROKE_PURE is supplied, can you offer some pointers on where to
> start looking in the PDFBOX source code?
>
> I understand this is a lengthy email. I greatly appreciate your time.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
Hi,
Your initial complaint was about PDFDebugger
PDFDebugger was mentioned because the top and bottom cut off symptom was
visible there as well as the PDFwriter.
The original symptom we observed was that the right side of the bordering
box on the PDF is cut off. This right side is only cut off when rendering
hints are set to VALUE_STROKE_PURE, otherwise the top and bottom are cut
off.
It was my initial assumption that the two symptoms are related, which is
why I mentioned PDFDebugger.
What I don't understand about the DPI comments is that I'm never actually
printing to a 72 dpi printer, so I would not expect the 72 dpi to be an
issue, but I still do not understand this concept in the PDF. I've used a
few tools to attempt to inspect the DPI of this document and I cannot find
an application that will report this information. Historically when
printing, I supply a density of zero, which seems to result in the best
print quality.
The PDF is likely fine. The bug is either with PDFBox or with Java itself.
> My suspicion is that it's a rounding error.
I feel that this statement slightly contradicts the statements about the 72
dpi being too low, hence my confusion. Regardless, where's the best place
to start looking in the codebase for this problem? For example, there are
some other artifacts as well, which may be related.
The problem is much more noticable using the CUPS PDF printer on Mac, but
even on Windows, there are some slight positioning and alignment
differences.
https://github.com/qzind/tray/assets/6345473/3022d304-1994-45bb-9907-b28a6692a8dc
I remember from working with PDFBOX on PDFBOX-4709 that some draw routines
lose precision at low printer DPIs, but this seems to be the opposite where
the document's DPI is low and causes the issue regardless of the printer's
DPI.
To prove that it is a jdk bug would require a lot of work, and even then
> it's unlikely it would be fixed
We sponsored this fix https://github.com/openjdk/jdk/pull/1183 so I'm
optimistic that if the issue is fixable that openjdk would be receptive to
a fix.
So if we're to isolate this issue simply to the right hand side missing
when VALUE_STROKE_PURE is supplied, can you offer some pointers on where to
start looking in the PDFBOX source code?
I understand this is a lengthy email. I greatly appreciate your time.
Re: Slight rendering issues Apache FOP document
Posted by Tilman Hausherr <TH...@t-online.de>.
default dpi means that it is rendered at 100%, i.e. 1 PDF unit = 1
screen unit. This is too small for a modern screen, and too small for a
printer. Like I wrote, a cheap label printer has more.
The unit is defined in the PDF specification ("user space unit is 1⁄72
inch").
There is no need to try anything.
PDFBox calculates the scale when printing. You could find the scale that
is used by setting a breakpoint on this line in PDFPrintable and look
for the scale:
renderer.renderPageToGraphics(pageIndex, graphics2D, (float) scale,
(float) scale, RenderDestination.PRINT);
If you use printing with a specific dpi then you can try specific
values, but then it will be rendered to an image first.
Your initial complaint was about PDFDebugger (which goes away at 150%)
and a PDF printer (which doesn't happen on windows, and besides your PDF
is already a PDF so it isn't needed), not about actual printing.
Tilman
On 18.10.2023 22:03, Tres Finocchiaro wrote:
>
> This bug with this file happens only at an unrealistic dpi.
>
>
> Is this something that I can change using PDFBOX APIs? I don't mind a
> code workaround as I'm using quite a few others for edge-cases such as
> this.
>
> I find it odd that you keep mentioning "unrealistic dpi" though. Can
> you help point me to where this DPI is defined or fetched?
>
> I did a quick search and most articles I'm finding say that 72 is the
> default DPI, is that not true?
>
> https://stackoverflow.com/a/14230982/3196753
> https://stackoverflow.com/a/55700705/3196753
> https://stackoverflow.com/a/63025632/3196753
>
>
>
> - Tres.Finocchiaro@gmail.com
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
>
> The PDF is likely fine. The bug is either with PDFBox or with Java itself.
> My suspicion is that it's a rounding error.
Thanks. Should I file a bug report against this behavior?
Somewhat unrelated but I tracked down the source of the PDF and it comes
from Pitney Bowes API:
https://docs.shippingapi.pitneybowes.com/carriers/pitney-bowes.html#pb-expedited-delivery-labels
.
- Tres.Finocchiaro@gmail.com
Re: Slight rendering issues Apache FOP document
Posted by Tilman Hausherr <TH...@t-online.de>.
Hi,
The PDF is likely fine. The bug is either with PDFBox or with Java
itself. My suspicion is that it's a rounding error.
72dpi and 100% is the same thing. 72 dpi is because a unit in PDF is
1/72 inch.
Tilman
On 18.10.2023 18:29, Tres Finocchiaro wrote:
> Hi, yes, I understand this, but are you saying it's a bug with the way the
> PDF is created? Since it contains mostly factor shapes, I would expect it
> to scale properly, as it does with other applications. Is this assumption
> wrong?
>
> The PDF is created by a 3rd party application (possible directly from the
> USPS) so as the receiver of this, I need to understand if there's a PDFBox
> code workaround to make this print like other PDF apps, if it's a bug with
> PDFBOX, or if the issue must be taken back to the source of the PDF to fix.
>
> For example, can this 72 dpi @ 100% be manipulated? The content
> should scale just fine and it looks crystal clear in all other PDF preview
> applications.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
Typo: it contains mostly *vector shapes
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
Hi, yes, I understand this, but are you saying it's a bug with the way the
PDF is created? Since it contains mostly factor shapes, I would expect it
to scale properly, as it does with other applications. Is this assumption
wrong?
The PDF is created by a 3rd party application (possible directly from the
USPS) so as the receiver of this, I need to understand if there's a PDFBox
code workaround to make this print like other PDF apps, if it's a bug with
PDFBOX, or if the issue must be taken back to the source of the PDF to fix.
For example, can this 72 dpi @ 100% be manipulated? The content
should scale just fine and it looks crystal clear in all other PDF preview
applications.
Re: Slight rendering issues Apache FOP document
Posted by Tilman Hausherr <TH...@t-online.de>.
72dpi is the 100% in PDFDebugger and in the renderImage() call with 1
parameter or with scale 1. Printers usually have a higher dpi. AFAIK
desktop printers have 1200 dpi. The first LaserJet printer had 300 dpi.
A cheap label printer has 203 dpi.
Tilman
On 18.10.2023 17:53, Tres Finocchiaro wrote:
> Is there a way to increase this programmatically? I'm still not sure what
> the 72 dpi is, is this something that can be adjusted? The contents of the
> PDF are predominantly vectors, so I would expect the document to scale up
> properly as it does for all other applications I've tested.
>
>
> - Tres.Finocchiaro@gmail.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
Is there a way to increase this programmatically? I'm still not sure what
the 72 dpi is, is this something that can be adjusted? The contents of the
PDF are predominantly vectors, so I would expect the document to scale up
properly as it does for all other applications I've tested.
- Tres.Finocchiaro@gmail.com
Re: Slight rendering issues Apache FOP document
Posted by Tilman Hausherr <TH...@t-online.de>.
IIRC it happened when a line or a very thin shape appeared at the edge
of a clipping region.
It didn't always go away at 150%, sometimes the increase had to be much
higher. I don't know what influence there is.
Tilman
On 18.10.2023 06:46, Tres Finocchiaro wrote:
>> We gave up on fixing that because it renders properly at higher
>> resolutions.
>
> Hi, can you help you explain what this means? For example, is there an
> attribute of the PDF that influences this 72 dpi that you're referring to?
> In the case of the document, I would expect it to scale proportionately to
> the output medium (e.g. 203 DPI, 300 DPI, 600 DPI, etc).
>
> The issue also appears to go away when rasterizing it to image first.
>
>
> - Tres.Finocchiaro@gmail.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Slight rendering issues Apache FOP document
Posted by Tres Finocchiaro <tr...@gmail.com>.
>
> We gave up on fixing that because it renders properly at higher
> resolutions.
Hi, can you help you explain what this means? For example, is there an
attribute of the PDF that influences this 72 dpi that you're referring to?
In the case of the document, I would expect it to scale proportionately to
the output medium (e.g. 203 DPI, 300 DPI, 600 DPI, etc).
The issue also appears to go away when rasterizing it to image first.
- Tres.Finocchiaro@gmail.com
Re: Slight rendering issues Apache FOP document
Posted by Tilman Hausherr <TH...@t-online.de>.
Yes, at 100% the top and bottom lines are missing. It gets better at 150%.
This has happened before with some files that lines are not rendered at
low resolutions, and 100% is 72 dpi. We gave up on fixing that because
it renders properly at higher resolutions.
Tilman
On 18.10.2023 03:02, Tres Finocchiaro wrote:
> Hi,
>
> I have a document (USPS shipping label) that was created using (what I
> believe to be Apache FOP) here:
>
> https://github.com/qzind/tray/files/12458435/Public-Test-Label.pdf
>
> Preview's inspector says:
>> "Apache FOP Version 2.3; modified using iText® 5.5.6 ©2000-2015 iText
>> Group NV"
>
>
> - When it's previewed in Previewer (MacOS), Chrome, Adobe Acrobat the
> outermost line/stroke is clearly viewable and easy to see.
>
> - When it's previewed in PDFDebugger, the top and bottom of the
> outermost line/stroke is missing.
>
> - When I print this document to a PDF printer on MacOS using rendering
> hint VALUE_STROKE_PURE, the top and bottom of this outermost line/stroke
> appear, but the right is cut off. (antialiasing hints on/off do not seem to
> impact this)
>
> Is the rendering of the outermost line/stroke simply a quirk to using
> PDFBOX, or is there a rendering issue?
>
>
> - Tres.Finocchiaro@gmail.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org