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
>
> > 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 differ
>
>
> 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
>
> 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
>
> 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-
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 wrote:
> On 11.11.2023 15:50, Tilman Hausherr wrote:
> >>
> >> Should th
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
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
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 disap
... also, replacing the border-width="0.5mm" with "1mm" everywhere in the
FO file is a viable workaround.
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?
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
>
> 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
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 Finocchia
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 of
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
>
> 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.shi
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 ar
Typo: it contains mostly *vector shapes
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 f
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 wro
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.finocc
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 be
>
> 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 proportiona
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, Tre
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
26 matches
Mail list logo
