Philipp Lohmann - Sun Germany wrote:
Giuseppe Castagno wrote:
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?
What i meant is the XMD metadata stream described in chapter 10.2.2 of
the PDFReference (1.6); the PDF/A spec requires this metadata stream.
This bascially contains information, hat we already have (producer,
author and such) plus a calibrated color space, that is needed to
calculate absolute color values out of the DeviceRGB values that we
currently have. Essentially we would be free to define that color space
since we do not support calibrated colors currently anywhere in OOo, so
this would basically be choosing a suitable calibrated RGB color space.
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?).
We already embed every font but the 14 standard fonts. This requirement
can be fullfilled by not adding the 14 builtin fonts in
PDFWriterImpl::filterDevFontList. The builtin fonts are not downloaded
but we use only their metrics which are compiled in and can be found in
vcl/source/gdi/base14.cxx.
I'll have a look.
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.
If that is only for level a, then we're almost good for level b anyway i
think.
After this brief exchange I think along the same lines.
One thing I do not know yet is how we can validate against the PDF/A
spec. I'd like to have some tool that tells me "conforming" or "not
conforming, section <xyz> violated" for a document.
About this I did a quick survey but so far only commercial product.
This one
http://www.pdf-tools.com/asp/products.asp?name=VALA
is an example.
I'll continue searching for validation tools, anyway. These are
something that is needed to do a good QA of the code.
--
Kind Regards, beppec56
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
