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.
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.
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.
Kind regards, pl
--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
-- Author unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
