You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by John Planow <jp...@parchment.com> on 2017/01/20 00:42:25 UTC
PDFRenderer Does Not Respect ExportState or ViewState in OCGs?
I'm using PDFRenderer.renderImageWithDPI() to create an image from a PDF
with a print watermark. The rendered image includes the watermark text. Is
this expected/desired behavior?
Here are some additional details..
I'm using a 2.1.0 snapshot of PDFBox.
The test PDF (attached) has the watermark text in an Optional Content
Group. The dictionary for this OCG dictionary looks like this:
<</Usage <</Export <</ExportState/OFF>>
/View <</ViewState/OFF>>
/Print <</Subtype /Watermark
/PrintState /ON >>>>
/Type /OCG
/Name (watermark)>>
I've attached the resulting image as well (outputImage.jpg). This doesn't
seem like the correct behavior and I'd be happy to file an issue and look
into it, but I want to be sure this isn't intentional.
With gratitude,
John
--
*JOHN PLANOW *| SOFTWARE DEVELOPER
jplanow@parchment.com
direct 916.367.6868 ext. 1623
3000 Lava Ridge Court, Suite 210, Roseville, CA 95661
*Parchment *| Turn Credentials Into Opportunities
www.parchment.com
Re: PDFRenderer Does Not Respect ExportState or ViewState in OCGs?
Posted by Tilman Hausherr <TH...@t-online.de>.
Am 20.01.2017 um 17:53 schrieb John Planow:
> Thanks for your response, Tilman.
>
> Your attachments didn't get through but I can guess what you mean... we
>> don't support the optional content groups while rendering, i.e. conditional
>> rendering. That's more like a new feature than a bug. Rather advanced
>> stuff. Yes create a new issue with your attachment(s) but don't expect this
>> to be done quickly.
>>
> Maybe an initial update could be to support the ExportState setting? This
> appropriate behavior with respect to this seems clearer, per the PDF spec
> (1.7):
>
> "This value indicates the recommended state for content in this group when
> the document (or part of it) is saved by a viewer application to a format
> that does not support optional content (for example, an earlier version of
> PDF or a raster image format)."
>
> As I mentioned, I'll be happy to take a look at the code to see if I can
> implement a suitable solution in a reasonable amount of time.
Sure, have a look... it is all available. There's also a thread from
June 2016, title "Suppressing layers on output"
https://mail-archives.apache.org/mod_mbox/pdfbox-users/201606.mbox/browser
There's some code and a discussion. Things became somewhat complex from
there on (or so it seemed).
Tilman
>
>
>> Another problem is that rendering does not "know" whether it is printing
>> or viewing.
>
> Yes, that's a very good point. It's not clear what the API should do
> regarding the print setting, absent of these other settings.
>
> With gratitude,
> John
>
> On Thu, Jan 19, 2017 at 11:01 PM, Tilman Hausherr <TH...@t-online.de>
> wrote:
>
>> Am 20.01.2017 um 01:42 schrieb John Planow:
>>
>>> I'm using PDFRenderer.renderImageWithDPI() to create an image from a PDF
>>> with a print watermark. The rendered image includes the watermark text. Is
>>> this expected/desired behavior?
>>>
>>> Here are some additional details..
>>>
>>> I'm using a 2.1.0 snapshot of PDFBox.
>>>
>>> The test PDF (attached) has the watermark text in an Optional Content
>>> Group. The dictionary for this OCG dictionary looks like this:
>>>
>>> <</Usage <</Export <</ExportState/OFF>>
>>> /View <</ViewState/OFF>>
>>> /Print <</Subtype /Watermark
>>> /PrintState /ON >>>>
>>> /Type /OCG
>>> /Name (watermark)>>
>>>
>>> I've attached the resulting image as well (outputImage.jpg). This doesn't
>>> seem like the correct behavior and I'd be happy to file an issue and look
>>> into it, but I want to be sure this isn't intentional.
>>>
>> Your attachments didn't get through but I can guess what you mean... we
>> don't support the optional content groups while rendering, i.e. conditional
>> rendering. That's more like a new feature than a bug. Rather advanced
>> stuff. Yes create a new issue with your attachment(s) but don't expect this
>> to be done quickly.
>>
>> Another problem is that rendering does not "know" whether it is printing
>> or viewing.
>>
>> Tilman
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: PDFRenderer Does Not Respect ExportState or ViewState in OCGs?
Posted by John Planow <jp...@parchment.com>.
Thanks for your response, Tilman.
Your attachments didn't get through but I can guess what you mean... we
> don't support the optional content groups while rendering, i.e. conditional
> rendering. That's more like a new feature than a bug. Rather advanced
> stuff. Yes create a new issue with your attachment(s) but don't expect this
> to be done quickly.
>
Maybe an initial update could be to support the ExportState setting? This
appropriate behavior with respect to this seems clearer, per the PDF spec
(1.7):
"This value indicates the recommended state for content in this group when
the document (or part of it) is saved by a viewer application to a format
that does not support optional content (for example, an earlier version of
PDF or a raster image format)."
As I mentioned, I'll be happy to take a look at the code to see if I can
implement a suitable solution in a reasonable amount of time.
> Another problem is that rendering does not "know" whether it is printing
> or viewing.
Yes, that's a very good point. It's not clear what the API should do
regarding the print setting, absent of these other settings.
With gratitude,
John
On Thu, Jan 19, 2017 at 11:01 PM, Tilman Hausherr <TH...@t-online.de>
wrote:
> Am 20.01.2017 um 01:42 schrieb John Planow:
>
>> I'm using PDFRenderer.renderImageWithDPI() to create an image from a PDF
>> with a print watermark. The rendered image includes the watermark text. Is
>> this expected/desired behavior?
>>
>> Here are some additional details..
>>
>> I'm using a 2.1.0 snapshot of PDFBox.
>>
>> The test PDF (attached) has the watermark text in an Optional Content
>> Group. The dictionary for this OCG dictionary looks like this:
>>
>> <</Usage <</Export <</ExportState/OFF>>
>> /View <</ViewState/OFF>>
>> /Print <</Subtype /Watermark
>> /PrintState /ON >>>>
>> /Type /OCG
>> /Name (watermark)>>
>>
>> I've attached the resulting image as well (outputImage.jpg). This doesn't
>> seem like the correct behavior and I'd be happy to file an issue and look
>> into it, but I want to be sure this isn't intentional.
>>
>
> Your attachments didn't get through but I can guess what you mean... we
> don't support the optional content groups while rendering, i.e. conditional
> rendering. That's more like a new feature than a bug. Rather advanced
> stuff. Yes create a new issue with your attachment(s) but don't expect this
> to be done quickly.
>
> Another problem is that rendering does not "know" whether it is printing
> or viewing.
>
> Tilman
>
Re: PDFRenderer Does Not Respect ExportState or ViewState in OCGs?
Posted by Tilman Hausherr <TH...@t-online.de>.
Am 20.01.2017 um 01:42 schrieb John Planow:
> I'm using PDFRenderer.renderImageWithDPI() to create an image from a
> PDF with a print watermark. The rendered image includes the watermark
> text. Is this expected/desired behavior?
>
> Here are some additional details..
>
> I'm using a 2.1.0 snapshot of PDFBox.
>
> The test PDF (attached) has the watermark text in an Optional Content
> Group. The dictionary for this OCG dictionary looks like this:
>
> <</Usage <</Export <</ExportState/OFF>>
> /View <</ViewState/OFF>>
> /Print <</Subtype /Watermark
> /PrintState /ON >>>>
> /Type /OCG
> /Name (watermark)>>
>
> I've attached the resulting image as well (outputImage.jpg). This
> doesn't seem like the correct behavior and I'd be happy to file an
> issue and look into it, but I want to be sure this isn't intentional.
Your attachments didn't get through but I can guess what you mean... we
don't support the optional content groups while rendering, i.e.
conditional rendering. That's more like a new feature than a bug. Rather
advanced stuff. Yes create a new issue with your attachment(s) but don't
expect this to be done quickly.
Another problem is that rendering does not "know" whether it is printing
or viewing.
Tilman