Hi Alban!
On Sun, 10 Apr 2005, [EMAIL PROTECTED] wrote:
> Step to reprduce:
> ----------------
>
> I reproduced this bug. One have to install gsfonts-x11, and have
> Type1 setted before 100 and 75dpi path in X config (or
> dynamically so via gxset/xset -fp)
Hmm, maybe xcalc is modified now, but if I try out
xset fp
/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi/,/usr/lib/X11/fonts/75dpi/
xset fp rehash
xcalc
(with gsfonts-x11 installed) everything looks correct.
> Then starting xcalc not only does those two characters (divide and
> root square) are not mapped to the same number (\270 is divide for
> adobe symbol fontspecific encoding, \330 for urw standard L
> fontspecific encoding)
According to the AFM files of URW Standard Symbols L and Adobe Symbol
this is not fully true:
s050000l.afm: C 184 ; WX 549 ; N divide ; B 10 2 536 525 ;
Symbol.afm: C 184 ; WX 549 ; N divide ; B 10 71 536 456 ;
s050000l.afm: C 216 ; WX 713 ; N logicalnot ; B 15 40 680 367 ;
Symbol.afm: C 216 ; WX 713 ; N logicalnot ; B 15 0 680 288 ;
As you can see, the metrics aren't identical, but according to these
AFM files, both fonts have "divide" on 184 (\270). The only
difference in the encoding is that the URW font contains the Euro
character on position 160, while this is undefined in the Adobe font.
After this I installed t1utils and run t1disam on both the Adobe
Symbol.pfa and the URW s050000l.pfb file. Both of them have an
encoding array at the top where a mapping between the char number and
the char name is defined. Both arrays are equal except the missing
"160 \Euro" in the Adobe font and both of them define
dup 184 /divide put
So I don't have an idea where you found the \330 (=216) in the URW
font.
> Fix:
> ----
>
> I don't think this should be fixed in the urw font (except if it
> told itself to be "fontspecific" compatible with adobe symbol).
> Though i wonder if it is a good adobe-symbol alias : the fonts
> mapped to it is :
> /usr/share/fonts/type1/gsfonts/s050000l.pfb
> /usr/share/fonts/type1/gsfonts/s050000l.afm
>
>
> /usr/lib/X11/fonts/misc/modd-iso8859-1-06x13-bold.pcf.gz from x11/xfonts-jmk
> and
> symb12.pcf.gz x11/xfonts-100dpi
> symb12.pcf.gz x11/xfonts-75dpi
>
> are good replacements for adobe standard as far as i tested them.
Bug pcf fonts aren't scalable. If you use them in a xfig (for
example), they look quite ugly when scaled to a size of 30 or 50
(instead of their rendered 6x13 or 12pt fixed size).
I think that it's necessary to have the standard Adobe Type1 fonts (or
their URW "copies") available in a scalable format.
Anyway, the question still is, whether s050000l.pfb is compatible to
the Adobe symbol font according to the encoding. I still cannot find
something wrong with this and never noticed one of the problems
mentioned in #239830 and #210362.
> NB: The previous submitter found ti was fixed as the newer
> xdebconf generated config files have
>
> FontPath "/usr/lib/X11/fonts/misc"
> FontPath "/usr/lib/X11/fonts/cyrillic"
> FontPath "/usr/lib/X11/fonts/100dpi/:unscaled"
> FontPath "/usr/lib/X11/fonts/75dpi/:unscaled"
> FontPath "/usr/lib/X11/fonts/Type1"
>
> mine which was hand modified so not updated for long had Type1
> first ...
That shouldn't make a difference in font encoding, but the above is
preferable, because unscaled pixel fonts usually look better for their
(small) fixed font sizes than the scalable Type1 fonts. But for large
scales that Type1 fonts are better.
I personally have
FontPath "/usr/lib/X11/fonts/100dpi/"
FontPath "/usr/lib/X11/fonts/75dpi/"
as a last resort at the end of my font path.
> Maybe the easier would be to remove any aliasing from the urw font
> to adobe symbol ...
I still don't see a real cause of this...
Tschoeeee
Roland
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
