Re: converting XFA PDFs using ghostscript - problem with encoding?

At 12:10 07/09/2017 +0200, Nikola Ciprich wrote:

> > The kind soul is incorrect, Ghostscript does not handle XFA.
>well, but it seems to work somehow, at least I can see the content
>now, even though encoding is not correct :)

That's because, as I said, AcroForms are not XFA, and not XML. Your file is 
both an XFA *and* an AcroForm. This is highly unusual (in fact I've never 
see it before, probably because of the risk of confusion), most XFA forms 
only contain enough PDF to draw a page saying 'go and get Acrobat'. By 
having both present you run the risk of the form data only being stored in 
one of the two forms.

You aren't dealing with the XFA here, because (as I said) Ghostscript 
doesn't handle XML, and therefore cannot read an XFA. Only the AcroForm is 
rendered, if the values stored in the AcroForm fields differ from those in 
the XFA dfields, then it will give different results.

Potentially you may receive a Form which is filled in using (eg) Acrobat, 
which looks correct when viewed with Acrobat, and prints completely 
differently when run through Ghostscript.


>in the meantime, I installed pdf  editor and examined source and produced
>file in more detail (as well as with pdffont) and seems that after all, 
>problem
>can be in fonts:

And the problem is what, exactly ? By the way, this is not a general 
support forum, and this question is off-topic. This mailing list is for 
development using Ghostscript, not usage.

Free users don't get support, here's my usual boolerplate on the subject:

8<-------------------8<------------------8<-----------------8<-------------------8<----
Thank you for your interest in Ghostscript. Ghostscript is supplied in two 
ways, as open-source software under the Affero General Public Licence 
Version 3 (http://en.wikipedia.org/wiki/Affero_General_Public_License) and 
as commercial software under licence from Artifex Software.

Please note that the '[email protected]' mail address is only for 
customers using Ghostscript or other software licenced commercially from 
Artifex. The AGPL version of Ghostscript is provided 'as is', without 
warranty or support.

We do value input from our free user community and we will fix bugs 
reported to us as well as considering enhancement requests. However, this 
is entirely at our own discretion and, as you would expect, our commercial 
customers are given priority over free users.

Bugs can be reported (and enhancement requests raised) at 
http://bugs.ghostscript.com there are a number of other avenues open to 
free users:

1) The stack overflow web site has a small but active community involved 
with Ghostscript, as well as PostScript and PDF. Questions raised here will 
often get a good response.

2) The Ghostscript developers can be found on the #Ghostscript IRC channel 
on irc.freenode.net. Questions asked here will usually get a response 
though time zone differences can mean there are periods when nobody is 
available. The channel is logged, the developers read the logs and will 
respond, so even if nobody answers immediately hang around, someone will 
eventually. Alternatively check back in the logs later.

Artifex does offer commercial distribution licences for Ghostscript , and 
in cases where this is not appropriate also offers support contracts. If 
you are interested in pursuing either of these please contact [email protected]

8<-------------------8<------------------8<-----------------8<-------------------8<----



>this is the gs produced pdf. examining file in pdf editor shows that 
>problematic part is the one
>with Helvetica font, with "Custom" encoding.. however how to proceed with 
>this information,
>I don't know yet :)

There are multiple problems.

The Annotations in the PDF do not contain Appearance streams. In the 
absence of an Appearance stream a PDF consumer may do anything, including 
nothing. For most annotations we choose to create an Appearance when one is 
missing.

But already you are into heuristics, because the way we create an Apperance 
is not the same as the way Acrobat does.

In order to create the Appearance we look at the properties of the 
annotation, in this particular case the annotations are drawn (/DA the 
default Appearance key)  using ArialMT. But we don't have a copy of ArialMT 
available. If you look at the transcript, you will see Ghostscript telling 
you this, and that it is substituting Helvetica for ArialMT:

GPL Ghostscript GIT PRERELEASE 9.22 (2017-03-16)
Copyright (C) 2017 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
Querying operating system for font files...
Substituting font Helvetica for MyriadPro-Regular.
Loading NimbusSans-Regular font from 
%rom%Resource/Font/NimbusSans-Regular... 39
73452 2485749 4730328 3370090 3 done.
Substituting font Helvetica for ArialMT.
 >>showpage, press <return> to continue<<


Perhaps unsurprisingly Helvetica does not (generally) have the accented 
characters you are using, our copy certainly does not, with the result that 
the text is incorrect.

If you supplied a reasonable substitute for ArialMT then its 'possible' you 
might get better results, but since that's is a TrueType font the results 
are likely to be variable. Getting the encoding correct is likely to be 
challenging.

However, nothing else is going to help you, you need to provide a 
substitute for the missing font, and it needs to have the glyphs available, 
and it needs to have them encoded in the right place for the text strings 
in the annotation.

If you do that, then it will work.


                 Ken