At 23:07 14/10/2009 -0400, Levi wrote:


>gs and extracted those folders into my gs8.63 folder so I could run
>the toolbin/genfontmap.ps .  Could this be part of my problem?  Is
>this not setup correctly?

Depends on the operating system and version of Ghostscript. GS uses a 'ROM'
file system (resources are compiled into the executable binary) for all
platforms today, but on Windows earlier versions used a disk file system.

Its always possible to override the ROM file system and use the files from
disk.


>GPL Ghostscript 8.63 (2008-08-01)
>Copyright (C) 2008 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
>Substituting CID font resource/Adobe-Identity for /ArabicTransparent.
>Error: /undefinedresource in findresource

OK, this tells us that the PDF file is indeed looking for a CIDFont named
ArabicTransparent. The PDF file you've sent in a different email contains
references to two fonts, one a CIDFont and one a regular Font, both called
ArabicTransparent.

Its hard to tell if that's the problem, I doubt it but it might be related,
these ideally ought to have different names.


>Do I need to setup a resource path to point to the "Resource"
>directory?  From the documentation it seems like it should
>automatically pick it up.  I am running the gswin32 from a command
>prompt from the bin directory.

If you don't want to use the ROM files (which you don't if you are
modifying the fonts, then you need to use the -I switch to add the
directories containing the Resource files to the GS search path.

You may already have an environment variable doing this.

Note that the GS_FONTPATH environment variable is probably already pointing
to your font location, where the ArabicTransport font is stored, this is
why you aren't getting an error on the regular font, just the CIDFont.

(actually I see that the installer created a fontmap for you with this font
already present)



>I've attached the output from this command, and it looks like it's
>picking up the font names correctly.
>Content-Type: application/octet-stream; name=generated_Fontmap
>Content-Disposition: attachment; filename=generated_Fontmap
>X-Attachment-Id: f_g0sx5lzu0
>
>Content-Type: image/png; name="pdf_fonts.png"
>Content-Disposition: attachment; filename="pdf_fonts.png"
>X-Attachment-Id: f_g0sxe2ac1

There's something of a puzzle here. The Acrobat font information says that
both ArabicTransport and ArabicTransport-Identity-H have an actual Font
Type of Type1. However the fontmap indicates that ArabicTransport is a
TrueType font:

(ArabicTransparent) (artro.ttf) ;

Is it possible you have the same font in different formats ? The fact that
Acrobat is using a different font to Ghostscript might lead to problems.

However, leaving that aside, I believe you will need to add ArabicTransport
as *both* a Font and a CIDFont for this to work. It seems that your
generated FontMap already contains an entry for ArabicTransport as a Font
(presumably as part of the installation process).

So, all you need to do is add a CIDFont. Going back to your original mail I
see you already have done this, and had some success, but the result was
not what you expected. What you specified was:

/ArabicTransparent << /FileType /TrueType /Path
(c:/windows/fonts/artro.ttf) /CSI [(CNS1) 4] >> ;

You've chosen a Chinese Ordering using Supplement 4, and you haven't
specified a SubfontID. I would suggest that you try a different ordering
and supplement. Identity would seem the most likely based on the content of
your later PDF file, but you might also try Unicode. Assuming that the font
is not a TrueType collection you probably don't need to worry about the
Subfont.

Eg:

/ArabicTransparent << /FileType /TrueType /Path
(c:/windows/fonts/artro.ttf) /CSI [(Identity) 0] >> ;

Or

/ArabicTransparent << /FileType /TrueType /Path
(c:/windows/fonts/artro.ttf) /CSI [(Unicode) 0] >> ;

Without seeing the font (and disassembling it to see what's inside) I can't
really help any further I'm afraid. Using a TrueType font to substitute for
a missing font is always somewhat difficult and prone to error. I would
suggest that if possible you embed the font (subset if required) in the PDF
file, its the only way to be certain that a PDF file will print correctly.



                     Ken
_______________________________________________
gs-devel mailing list
gs-devel@ghos...
http://www.ghostscript.com/mailman/listinfo/gs-devel