[ 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