Hi Yuri,
>>The name of the device font that matches
>>most closely on is in the ImplFontSelectData.mpFontData->maName. On your
>>system there is probably just OpenSymbol, so when an application requests
>>StarSymbol, which isn't available, this one gets chosen.
>
> ah, here is the problem: the OS/2 logical font API does a best match
> unless a unique system id is passed; this id is enumerated in the
> Os2SalGraphics::GetDevFontList.
>
> But in latest code, I removed use of this id, thus leaving the OS/2
> graphic engine to select a best match based on name, style, size and so
> on.
>
> So without a StarSymbol font, OS/2 selected a different font that
> matches most required fields, but this was not a symbol font. And the
> call did not fail obviously.
Yes that explains the problem with OpenSymbol/StarSymbol.
Other than that problem I'd suggest to reintroduce the unique system id for
fonts. Only with this approach we can work with all the fonts that OS/2
never heard of, like the many mentioned in OOo's (in-)famous VCL.xcu
configuration file.
> Maybe this could explain another bug: truetype bold fonts are exported
> to pdf using emulated bold, then they looks ugly compared to normal
> output.
Please see vcl/source/gdi/pdfwriter_impl.cxx for details on when the
emulated boldness is triggered:
(maFontSelData.mpFontData->GetWeight() <= WEIGHT_MEDIUM)
&& (maFontSelData.GetWeight() > WEIGHT_MEDIUM)
This means that if the requested font is bold and the selected device font
has medium weight then the exported text gets emulated boldness.
--
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
