Re: PDF full screen mode...

[Andreas Delmelle-2]

On Jul 17, 2008, at 15:07, Bill Harrelson wrote:

Hi Bill

> Thank you very much! (in advance).
> I have a client that prints labels that we generate with fop to a  
> pdf file, but the default print settings are "Scale to fit", and  
> we're printing full bleed, so we need to set PrintScaling to 'None'  
> in the document.

Before sending you the files and wasting your time, I'm checking also  
on fop-dev@, since I'm not sure whether this particular requirement  
can already be met by my patch. I've searched through the PDF  
Reference (1.5), and could not find any reference to an entry called  
'PageScaling'. It's possible that this can be achieved by a  
combination of other entries, but to be honest, unless you already  
have a very good idea of what you want the patch for, I'm afraid it  
may prove to be too limited FTM... :/

If there is no such entry/value in PDF, then specifying it might  
cause FOP to produce PDF on which the average PDF Viewer would choke.



Cheers

Andreas

[Jeremias Maerki-2]

For that you need an "Explicit Destination" (PDF 1.4, 8.2.1, "[page /Fit]")
which you place as a value for the "OpenAction" key in the "Document
Catalog".

On 17.07.2008 18:31:13 Andreas Delmelle wrote:

>
> On Jul 17, 2008, at 15:07, Bill Harrelson wrote:
>
> Hi Bill
>
> > Thank you very much! (in advance).
> > I have a client that prints labels that we generate with fop to a  
> > pdf file, but the default print settings are "Scale to fit", and  
> > we're printing full bleed, so we need to set PrintScaling to 'None'  
> > in the document.
>
> Before sending you the files and wasting your time, I'm checking also  
> on fop-dev@, since I'm not sure whether this particular requirement  
> can already be met by my patch. I've searched through the PDF  
> Reference (1.5), and could not find any reference to an entry called  
> 'PageScaling'. It's possible that this can be achieved by a  
> combination of other entries, but to be honest, unless you already  
> have a very good idea of what you want the patch for, I'm afraid it  
> may prove to be too limited FTM... :/
>
> If there is no such entry/value in PDF, then specifying it might  
> cause FOP to produce PDF on which the average PDF Viewer would choke.
>
>
>
> Cheers
>
> Andreas

Jeremias Maerki

[Andreas Delmelle-2]

On Jul 17, 2008, at 18:53, Jeremias Maerki wrote:

> For that you need an "Explicit Destination" (PDF 1.4, 8.2.1,  
> "[page /Fit]")
> which you place as a value for the "OpenAction" key in the "Document
> Catalog".

Thanks for the pointer! Unfortunately for Bill, this means that the  
patch will need some more work to support (at least) PDF arrays as  
well, before the extension can be used for this purpose.

I don't think adding arrays by itself would be too difficult. I was  
playing with the idea of using strictly typed objects (in favor of a  
type attribute on an abstract entry), which I'll probably add pretty  
soon. I'll see what I can do.
The only potentially tricky part may be the indirect reference to the  
page object (?)

IIC, this is a variable that the extension knows nothing about  
(should be set/provided by the renderer)

Apologies for the false hope for an immediate solution, Bill. On the  
bright side, it's probably not too far away...


Andreas

[Jeremias Maerki-2]

I've been quiet about about this PDF extension so far because I didn't
see much harm in doing it in a generic way for some simple name/value
pairs. If that goes much further (like doing hacks to produce some
complex PDF structures but still forcing it into the generic extension)
then I'm a bit concerned. I do prefer the non-generic form I proposed at
the beginning on the Wiki. I don't think there will be any problems with
PDF/A and PDF/X conformance but the further you go with a generic
approach the less control you have if a generated file will be
conformant. Please keep that in mind while working on this. Thanks.

On 17.07.2008 19:18:32 Andreas Delmelle wrote:

> On Jul 17, 2008, at 18:53, Jeremias Maerki wrote:
>
> > For that you need an "Explicit Destination" (PDF 1.4, 8.2.1,  
> > "[page /Fit]")
> > which you place as a value for the "OpenAction" key in the "Document
> > Catalog".
>
> Thanks for the pointer! Unfortunately for Bill, this means that the  
> patch will need some more work to support (at least) PDF arrays as  
> well, before the extension can be used for this purpose.
>
> I don't think adding arrays by itself would be too difficult. I was  
> playing with the idea of using strictly typed objects (in favor of a  
> type attribute on an abstract entry), which I'll probably add pretty  
> soon. I'll see what I can do.
> The only potentially tricky part may be the indirect reference to the  
> page object (?)
>
> IIC, this is a variable that the extension knows nothing about  
> (should be set/provided by the renderer)
>
> Apologies for the false hope for an immediate solution, Bill. On the  
> bright side, it's probably not too far away...
>
>
> Andreas

Jeremias Maerki

[Andreas Delmelle-2]

On Jul 17, 2008, at 20:08, Jeremias Maerki wrote:

> I've been quiet about about this PDF extension so far because I didn't
> see much harm in doing it in a generic way for some simple name/value
> pairs. If that goes much further (like doing hacks to produce some
> complex PDF structures but still forcing it into the generic  
> extension)
> then I'm a bit concerned. I do prefer the non-generic form I  
> proposed at
> the beginning on the Wiki. I don't think there will be any problems  
> with
> PDF/A and PDF/X conformance but the further you go with a generic
> approach the less control you have if a generated file will be
> conformant. Please keep that in mind while working on this. Thanks.

OK, will do. As a plain and simple rule, I'd make it "either one or  
the other". If the user specifies a conformance level, processing of  
the extension is disabled, since otherwise FOP cannot guarantee the  
conformance.

I see perfectly what you mean, and the idea of specifying PDF  
'expressions' is way too dangerous to allow. That's why I'd like to  
limit it to a handful of elements that, when combined, can serve to  
compose simple dictionaries/entries. Obviously, the docs will have to  
come with a Big Fat disclaimer that users are advised to stick to the  
examples that we provide, unless they are absolutely certain they  
know what they're doing...

In the meantime, I have received another reply from Bill, which  
raises some more concerns (something that was already playing in the  
back of my mind), namely, users that specify PDF 1.6 entries in a  
document whose header indicates PDF 1.4. Not sure, but this is very  
likely to cause unpredictable behavior in certain viewers... Some may  
simply ignore the entry, others might consider the PDF to be corrupt/
invalid.

Bill, note that the entry in question may well be available in the  
ViewerPreferences dictionary as of PDF 1.6, but FOP still produces  
PDF 1.4 max.


Cheers

Andreas

[Andreas Delmelle-2]

On Jul 18, 2008, at 19:24, Bill Harrelson wrote:

Hi Bill

> Thanks.  Guess I just have to wait, and tell the users they have to  
> check print scaling when they print.
>
> I tried patching a pdf file by hand to include the directive, and,  
> as you predicted, got file corrupted errors (although that could be  
> for a variety of reasons, so it's not conclusive.)

In theory PDF is editable by hand, but remember that it's still a  
binary format, so it's /very/ sensitive to things like editors adding  
linefeeds or screwing up the raw bytes due to implicit byte-to-char  
conversion... You'd actually almost need a Hex editor to get it  
completely right.

Anyway, I ran a test out of curiosity. It doesn't crash or give  
corruption warnings on my end (Adobe Reader 8 for Mac), and checking  
the document properties, the entry even seems to be correctly  
recognized (meaning Reader does not rely on the PDF file version to  
process the ViewerPreferences). Also, adding totally nonsensical  
entries, which would generate PDF like '/Foo /Bar' (strictly speaking  
not incorrect, just meaningless) did not have any damaging effects.

In the end, if it works, it works, I guess, so I'm not so sure  
whether it's worth investing time into making things like that  
impossible, BUT... if the user would specify something like  
'<pdf:name key="Foo">[[Bar</pdf:name>', the file does get corrupted,  
since the content is not a valid PDF name. Some degree of validation  
is necessary to prevent this stuff from happening. The square  
brackets should either be escaped (to '#5B'), or made illegal (i.e.  
if necessary, the user should do the escapes himself). Maybe it would  
make sense to have PDFName itself not allow invalid names to be  
created. At any rate, additional logic for PDF parsing capabilities  
seems to belong in the fop.pdf package, rather than on the side of  
the extension.

Ultimately, it's also meant to reduce maintenance on our end. If the  
PDF Reference evolves and allows new features, the extension should  
make those available to the users with us having to add only a  
minimal amount of code. None in case of the PrintScaling entry, since  
there is already generic support for PDF names. Nice example of the  
potential benefits, as opposed to the dangers described above.

I'm currently still planning to look into making a few modifications  
to the format, and building in some safeguards (basic validation, if  
you will). If you want to stay informed, add yourself to the CC-list  
in Bugzilla #45390, and you'll be among the first to receive updates  
on the status of the patch.



Cheers

Andreas