[
https://issues.apache.org/jira/browse/PDFBOX-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875016#comment-15875016
]
Emmeran Seehuber commented on PDFBOX-3697:
------------------------------------------
[~lancess] Its not only about drawing SVGs on a PDF. Its about drawing anything
which takes a Graphics2D on a PDF. We currently use JasperReports with iText
for some of our reports and use the Graphics2D support of iText to draw charts
using JFreeChart. We want to migrate away from JasperReports to OpenHtmlToPdf
in the mid/long term. And for that OpenHtmlToPdf must have the possibility to
let some objects draw them self using a Graphics2D.
[~tilman] Writing 16 bit images is unusual, but required if you want (for what
ever reason) to write ProPhoto images. ProPhoto is a very wide colorspace. If
you write ProPhoto with 8 bit per channel you get some visible color stepping,
which is bad.
In one application of mine I have to size images down (resample), because they
should be printed at 300 dpi, but are sometimes 1200 dpi or more. Those images
take ages to render in the PrePress RIP. To correctly resample an image you
need a fully linear colorspace, otherwise you might get color shifts, because
the gamut is not linear. E.g. adding 1 to green in sRGB does make the color
more or less green depending on its current value. In a fully linear colorspace
adding 1 to green always makes the color the same amount more green. ProPhoto
is such a colorspace and big enough so that high quality photographer photos
with different colorspaces fit in it without any loss - if you use 16 bit. I've
build myself a 16 bit lossless PDF image encoder which I use with the ImgRaw
class of iText (because I still use iText 2.1 in that application, but I want
to migrate away to PDFBox in the long term; I also had to patch iText because
it did not support 16 bit images at all https://github.com/rototor/itext).
The problem is, that 16 bit images are a PDF 1.5 feature. But PrePress
workflows are often still on PDF 1.4. Which means that in my case the 16 bit
ProPhoto images were printed perfectly on a HP Indigo, because the RIP of the
HP Indigo can handle that. But when the same PDF was put through the PDF
workflow of the printing shop it broke all images. I have to convert the images
in that application to a 8 bit CMYK target colorspace for now after resampling
the images in ProPhoto.
So, yes 16 bit images are still not so common, because there is enough software
which can not handle it. But normal PDF viewers (Acrobat, MacOS Preview, even
the PDFBox debugger) can handle those fine. If I find time I might contribute
the 16 bit image encoder.
> RFC: Integration of Graphics2D->PDFBox bridge
> ---------------------------------------------
>
> Key: PDFBOX-3697
> URL: https://issues.apache.org/jira/browse/PDFBOX-3697
> Project: PDFBox
> Issue Type: Improvement
> Components: Writing
> Reporter: Emmeran Seehuber
> Priority: Minor
>
> I've build a Graphics2D -> PDFBox bridge. It allows you to draw using
> Graphics2D into a PDF. iText has such a feature for a long time now. In
> PDFBOX-102 it seems you don't want such a feature, or at least don't want to
> implement it. I hope I must not explain why drawing to an image and placing
> that image in the PDF is *not* the right solution. Depending on the output
> device this may result in horrible quality.
> As I want to migrate my usages of flying-saucer to openhtmltopdf
> (https://github.com/danfickle/openhtmltopdf) I need a way to embed report
> graphs in high quality into the PDF. Because of this I build this bridge:
> https://github.com/rototor/pdfbox-graphics2d
> The bridge is build from ground up by myself. I did not use any code of the
> iText-Graphics2D bridge.
> Currently it can render text only as vector shapes. But it supports different
> gradient paints and texture paints. openhtmltopdf uses it to draw inline SVGs.
> I would like to contribute this bridge to PDFBox, as I think this is a
> feature PDFBox currently lacks. But I am not sure if you want this at all.
> The bridge uses reflection to access e.g. the Batik gradient paints without
> referencing Batik. The paint mapping is something which can never be really
> finished, as they can be many paint implementations. Because of this the
> bridge allows to customize all different kind of mappings (color/paint/font).
> I don't know if it is better to keep this bridge separate or if it is better
> to integrate it into PDFBox. This is something I would like you to decide. If
> you would like it, I would prepare a patch.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
