In message <57606391.1030909@xxxxxxxxxxxxxxxxx>
John Tytgat <john@xxxxxxxxxxxxxxxxx> wrote:
On 06/14/2016 02:39 PM, Gavin Crawford wrote:
[...]
I'm trying to get an understanding of the way the PS3 driver includes
the fonts in the PostScript output file. On the older (Acorn) PS2
driver, if any fonts contain a Type1 file (it is my understanding)
that this Type1 data is used in the PS output file. Is this still the
case for the PS3 driver?
Yes. If not, we create a Type1 or CID font and embed & use that in our
PostScript file.
Getting to the point of why I'm aksing:
I notice that text in the PDF that uses the EFF fonts can be copied
and pasted into a text editor and the text is correct. In other words,
the characters are correct. Where as, with my font (or indeed any
other standard RISC OS outline font that only has Outlines and
IntMetrics files) the characters are not correct when copied and
pasted - they seem to be odd control codes. Although, they 'look'
correct in the PDF in as much as the shapes displayed in the PDF
document have the right matching shapes as the font, when examining
the containing text object data in Acobat's page content tree all the
non EFF font text is just represented as dots.
What causes the difference between the fonts and how can I ensure that
my font retains the correct characters embeded in the PDF.
If you really only have an "Outlines" and "IntMetrics" file and they do
not have a number suffix in their name, then that's a symbolic font.
That means that basically we do not know that an, e.g., 'a' looking
character really means the letter 'a'. And probably by cheer 'luck' you
have that 'a' looking character at position 97 which happens to be
selected when you type 'a' on your keyboard. Unless you have an
"Encoding" file which tells you for each character what its glyphname is.
For correct print output we (or a PostScript printer, or PostScript to
PDF converter) do not really need to know that information. However, if
you do cut & paste of text in your PDF viewer, at that point it is
relevant to know that the 'a' looking character is an 'a' because that's
what going to end up in your cut & paste buffer and being used in the
application where you pasted your text in.
When Acrobat is distilling your PostScript file, it tries to
semantically derive the meaning of the characters defined in a font and
will store this in the PDF file (ToUnicode data-structure). This happens
based on glyphnames used in the Type 1 font. When you have a RISC OS
font with a defined encoding (either based on the suffix of
"Outlines"/"IntMetrics" filenames, either a separate Encoding file for
symbol fonts) and when we're able to extract those glyphnames from the
encoding file, we use those instead of creating our own artificial ones
so in those cases your cut & paste is most probably going to result in
meaningful text.
If there is an existing Type 1 font, we'll use that instead then most
probably it has meaningful glyphnames which can get recognized by the
Distiller.
So bottomline, I think you probably need an Encoding file for your
font. Can't you create that using FontFiend ?
