You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Andreas Delmelle <an...@telenet.be> on 2008/07/17 18:31:13 UTC
Re: PDF full screen mode...
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
Re: PDF full screen mode...
Posted by Andreas Delmelle <an...@telenet.be>.
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
Re: PDF full screen mode...
Posted by Andreas Delmelle <an...@telenet.be>.
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
Re: PDF full screen mode...
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: PDF full screen mode...
Posted by Andreas Delmelle <an...@telenet.be>.
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
Re: PDF full screen mode...
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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