Philipp Lohmann - Sun Germany wrote:
Giuseppe Castagno wrote:
Philipp Lohmann - Sun Germany wrote:
Not me. However it is a requested feature (as you already know :-),
issue 59651). I think PDF/A level a would not be too hard to
implement based on the current code (mostly one needs to switch off
some features).
mm... not sure about this.
It seems to me (almost exact Norm wording):
- PDF/A-1a conforming file shall adhere to all ISO-19005-1:2005;
- PDF/A-1b conforming file shall adhere to all ISO-19005-1:2005 except
6.3.8 (Unicode character maps) and 6.8 (Logical Structure).
snip...
One of the 'to be implemented' features is 6.7 (Metadata), this seems
partly similar to point 9.2.2 of PDF 1.4 specification.
A wild thought. Can this one be implemented apart from PDF/A, as an
added point to PDF 1.4?
Sure. But if I remember correctly that's about the only real feature
needed for PDF/A level a (or am i confusing level a and b here ? I mean
the less restrictive one) and it is not really hard to do IMHO as it is
only about packaging the metadata we already emit in an extra XML stream.
I think you are talking about the b level (PDF/A-1b, point 5.3 of the
Norm), and I guess the XML metadata stream you are talking about is the
'main' stream that deals with Open Documetn format, since in PDF output
filter I don't see anything of the sort, right?
The rest is mostly about the PDF formatting itself (PDF/A e.g. requires
single spaces between object numbers and the "obj" statement). Also one
must embed the standard fonts (Times, Helvetica, Courier), which we
currently don't do as every reader must bring those with it.
I think that here it's a matter of forced embedding, even though I have
no Idea what should be done on platforms where those fonts are not
present (I'm not a font expert, are they always present in every
platform OOo is compiled on?).
One problem remains with the embedded fonts. The standard does not tell
whether our method of font embedding is ok, namely using an arbitrary
encoding (which the standard frowns upon) as long as there are ToUnicode
maps available (which seems to be ok). This could be easily fixed for
IS08859-15, some more work required for single byte encodings but would
require more serious rework for multibyte encodings and such. If this
were required by the PDF/A standard (which is not clear to me) we should
switch the whole way to emitting unicode (instead of the current single
byte "special encoded" character stream).
I don't know the details of Unicode mapping on PDF output filter, but
the only Norm points where Unicode mapping is somehow explained/dealt
with are 6.3.8 and 6.8, the ones not needed for level b conformance.
--
Kind Regards beppec56
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
