[gs-devel] ArabicTransparent and ArabicTransparent-Bold Fonts

[Levi]

Thanks again, Ken.  I will look into the cidfmap again to see if I can
get the right ordering and supplement.  Is there a way to figure it
out from the TTF?  I attempted to load the font with fontforge, but
wasn't sure where to locate that information or even if it was in it.

I'm attaching the two fonts that enable me to see the PDFs in Adobe
Reader as well as Foxit Reader.  Note that they are copyrighted so
they're not embeddable.

Thanks to the both of you for your time and quick responses in helping
me try to address this issue, and keep up the great work.

On Thu, Oct 15, 2009 at 3:45 AM, Ken Sharp <ken.sharp at artifex.com> wrote:
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arabic_fonts.zip
Type: application/zip
Size: 88443 bytes
Desc: not available
Url : http://ghostscript.com/pipermail/gs-devel/attachments/20091015/a0fdb624/arabic_fonts-0001.zip