[Scribus] Re: Encoding problem with rich Type1 font
Sun Aug 28 20:26:04 CEST 2005
I reported this problem as bug #2494 on bugs.scribus.net.
> 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 18.104.22.168+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:
> instead of
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
I will look into this further when we update the textsystem; alternate
glyphs, ligatures etc. are on our todo list anyway.
More information about the scribus