Hi,

the problem is that I have a pdf file produced
out of a handcrafted postscript one by ghostscript.  There
I use the same true type font (Verdana) in
different encodings (latin1 and altered koi8-r).
When I view the file via acroread (4 and 5) all
is right, when I print the postscript file via
ghostscript: no problem.  But when printed by
acroread some encodings are substiuted by a single
char, in some encodings various positions
are changed to another one, e. g. space, comma, numbers
parenthesis to 9.

After having a glimpse on your news group
I put all glyphs encoded between 000 and 005
to 101 and 106, but it is still the same
problem (despite 9 there y is appearing now)

Any ideas?

Regards

Mirko Scholz

gnnggb@polbox.com (Mirko Scholz) wrote:

>Hi,
>
>the problem is that I have a pdf file produced
>out of a handcrafted postscript one by ghostscript.  There
>I use the same true type font (Verdana) in
>different encodings (latin1 and altered koi8-r).

Possibly, you have two different embedded font data sets? If you do,
be sure to either mark both of them as subsets, or to include an
explicit Encoding object that is different for each font object.

Otherwise Acrobat may consider that the font with identical (or
default) encoding and the same name is actually the same font, causing
more problems than this.
----------------------------------------
Aandi Inston  quite@dial.pipex.com http://www.quite.com
Please support usenet! Post replies and follow-ups, don't e-mail them.

quite@dial.pipex.con (Aandi Inston) wrote:
> >the problem is that I have a pdf file produced
> >out of a handcrafted postscript one by ghostscript.  There
> >I use the same true type font (Verdana) in
> >different encodings (latin1 and altered koi8-r).
> 
> Possibly, you have two different embedded font data sets? If you do,
> be sure to either mark both of them as subsets, or to include an
> explicit Encoding object that is different for each font object.
    Well, I have never cared that much the font stuff of plrm.pdf.
(It's mere hobbyistic).  But may it is all very simple.  I have
used the following code to recode the font (found somewhere in comp.text.ps):

/reencode { dup length 5 add dict begin{1 index /FID ne{def}{pop pop}ifelse
}forall/Encoding exch def/FontBBox load aload pop FontMatrix transform/Ascent
exch def pop FontMatrix transform/Descent exch def pop/FontHeight Ascent
Descent sub def/UnderlinePosition 1 def/UnderlineThickness 1 def currentdict
/FontInfo known{FontInfo dup/UnderlinePosition known{dup/UnderlinePosition get
0 exch FontMatrix transform exch pop/UnderlinePosition exch def}if dup
/UnderlineThickness known{/UnderlineThickness get 0 exch FontMatrix transform
exch pop/UnderlineThickness exch def}if} if currentdict end}bind def

/reencode_font{findfont reencode 2 copy definefont pop def}bind def

and then

/fVerdana ISOLatin1Encoding /Verdana reencode_font

> Otherwise Acrobat may consider that the font with identical (or
> default) encoding and the same name is actually the same font, causing
> more problems than this.
    And why does the problem appear only when printing?

Regards

Mirko

gnnggb@polbox.com (Mirko Scholz) wrote:

>    Well, I have never cared that much the font stuff of plrm.pdf.

Forget what I said, it applies to handcrafted PDF, not distilled PS.

May be worth sharing a sample file (perhaps PS and PDF) on a web or
FTP site.
----------------------------------------
Aandi Inston  quite@dial.pipex.com http://www.quite.com
Please support usenet! Post replies and follow-ups, don't e-mail them.

quite@dial.pipex.con (Aandi Inston) wrote:

> May be worth sharing a sample file (perhaps PS and PDF) on a web or
> FTP site.

Ok,          
          
I have put two files at
          
     http://www.polbox.com/g/gnnggb/reproduce_error.ps
     http://www.polbox.com/g/gnnggb/reproduce_errorE.pdf
        
the second was produced out of the first by
             
     ps2pdf13 -dPDFSETTING=/prepress ...

with verdana.ttf in GS_FONTPATH, and added for 
your convenience.
    
As you see, when printing reproduce_errorE.pdf with
acroread, all characters that belong to latin1 and
koi8-r are replaced by Os in the Russian text.
Xpdf's pdftops reports the following error
"Illegal bfrange block in ToUnicode CMap".  Is 
it an error in ghostscript?  I bet no since
I therefore updated to version 8.11.

Regards

Mirko Scholz

In article <79a396.0311102243.77cc4ac2@posting.google.com>, Mirko Scholz wrote:
> I have put two files at
>           
>      http://www.polbox.com/g/gnnggb/reproduce_error.ps
>      http://www.polbox.com/g/gnnggb/reproduce_errorE.pdf
>         
> the second was produced out of the first by
>              
>      ps2pdf13 -dPDFSETTING=/prepress ...
> 
> with verdana.ttf in GS_FONTPATH, and added for 
> your convenience.
>     
> As you see, when printing reproduce_errorE.pdf with
> acroread, all characters that belong to latin1 and
> koi8-r are replaced by Os in the Russian text.
> Xpdf's pdftops reports the following error
> "Illegal bfrange block in ToUnicode CMap".  Is 
> it an error in ghostscript?  I bet no since
> I therefore updated to version 8.11.

That error from Xpdf was a bug -- it's fixed in Xpdf 2.03.  Pdftops
2.03 handles this file correctly.

I have no idea what's going on with Acrobat, though.  I tried using
Acroread on Linux to convert your PDF file back to PostScript, and saw
the same problem you did (bad characters when viewed with
ghostscript).

- Derek

Hi,

since nobody seems to know any solution, I will present
my workaround.  I converted the ttf file into two type 1
fonts of the two encodings.  To avoid naming conflicts
I renamed the ones in latin 1 (the /FontName in the
dictionary, of course).  Then the file produced
by acroread is ok.  The only thing important
to consider is that the ISOLatin1Encoding vector holds
/minus instead of /hyphen, but that could be easily
fixed.

Regards

Mirko Scholz