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
