[Scribus] Re: Encoding problem with rich Type1 font

[Andreas Vox]

Hi Ralf,

I reported this problem as bug #2494 on bugs.scribus.net.

Ralf wrote:
> Hi,
>
> I am currently developing a set of Type1 fonts with a rich set of
> glyphs. Small caps, old-style figures etc are contained within one PFB
> file per shape/weight. The glyph naming follows the new guidlines from
> Adobe, ie, a.sc instead of Asmall, one.oldstyle instead of oneoldstyle
> etc. A simple way to get a font like this is to run 'cfftot1' on, eg,
> MinionPro-Regular.otf. If I try to use either one of my fonts or the
> such created MinionPro-Regular.pfb together with scribus (version 1.2.1
> from Debain Sarge as well as versions 1.2.2.1+cvs20050805 and
> 1.3.0+cvs20050801 from debian.scribus.net), I get a wierd mixture of
> normal lowercase and small cap glyphs. For example, in 'Dies ist ein
> Blindtext', all occurences of 'i', 'n', 's' and 't' are actually small
> caps glyphs, while 'd', 'e', 'l' and 'x' are normal lowercase glyphs. A
> similar mixture occurs among the figures and accented letters.
>
> This happens both on screen and when producing a PDF file. Converting
> the PDF to PS using pdftops one can see that the encoding vector used
> indeed contain a simingly random mixture of different glyphs:
>
> /h.sc/i.sc/j.dotless/k/l/m/n.sc/o.sc
>
> instead of
>
> /h/i/j/k/l/m/n/o


Currently Scribus can not cope with fonts which assign the same Unicode 
value to different glyphs (and I'm not sure if this is legal at all). I 
checked MinionPro-Regular and it shows
unicode values in the Corporate use area for oldstyle figures (couldn't 
find any smallcaps).
If you have a font which encodes j.dotless as U+006A that font is 
broken IMO.

I will look into this further when we update the textsystem; alternate 
glyphs, ligatures etc. are on our todo list anyway.

/Andreas