Re: Bitmap font resizing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hi everyone,

Replying to all three responses in one email:

On 12-12-24 09:10 PM, Akira TAGOH wrote:
> Hi,
> I'm not sure if bitmap scaling is really expected things as the
> outcome on the request. I'm thinking of other possibilities too as
> someone was sometimes raising the sort of "How to stop fallback" or
> something like that. for instance, how about adding new binding mode
> to ask for strict matching, and if no candidates, simply fails?

That would be useful.  But how do you define "strict" matching exactly?
I think that's a separate issue though.  In the project I'm working on right
now I really do want bitmap scaling.

On 12-12-25 02:01 AM, Werner LEMBERG wrote:
> Indeed.  Bitmap fonts scaled by non-integer values look horrible if
> the output is B/W, and just a bit better if the target is grayscale
> (this is, the scaling has been done with proper dithering).

Not really, if you have, say, 128x128 grayscale bitmaps to start with...
Anyway, I'm not suggesting that everyone should get their 12px bitmaps scaled.
 I'm just enabling a way to configure it if it's desirable.  For example, not
"scaling" in PS/PDF/SVG outputs of cairo simply doesn't make sense.  If
metrics-hinting and hinting are disabled, scaling is the only correct thing to do.

On 12-12-25 07:57 AM, Raimund Steger wrote:
> I tend to agree, it's probably hardly worth the trouble, after all, any sane
> fontconfig configuration should direct matches away from bitmap fonts if the
> size difference is too considerable.

Unfortunately that's not even possible right now.

> But then I see and just
> in case it is related, I think for targets like PS or PDF where bitmap
> fonts are  scaled anyway it's maybe something that could be thought about.

Exactly.  We can make the default configuration do something very sensible.

> Also, _down_scaling large bitmap glyphs to grayscale by 50% or more could
> probably look OK even on image targets. Everything else, I'm not so sure.
> What  I definitely wouldn't want is all Cairo-based applications suddenly
> rendering upscaled 12px or downscaled 14px just because some CSS style
> computation ends at 13px, but OK, Behdad states that for small size
> differences it doesn't make sense anyway.

Exactly.  If metrics hinting is enabled and size difference is less than 20%,
don't scale.

> As for the config suggested. It generally doesn't seem like a bad idea to
> allow sub-expressions in <matrix> elements, if it's not too complicated to
> implement.

Agreed.  I'll take a look.

> Maybe one could also expose both pattern and font pixelsizes to
> expressions, something like <name target="pattern">pixelsize</name> vs.
> <name target="font">pixelsize</name>?

I really like this.  It's the right thing to do.  I wonder whether it already
works that way!  Will check and implement if it's not.

> I'm not sure about using the 'dpi' and 'size'
> properties to calculate the scaling factor because these properties will not
> always be there.

Agreed.  The target="font" approach is the right way to do it.

> But in the end, even if fontconfig isn't changed an application could still
> add that scaling itself by just comparing pixelsizes before and after
> FcFontMatch and adding the necessary properties, right?

Well, yeah, but then you can't have config that, say, scales certain fonts.
The trick is to have the fontconfig config being discussed here very early in
the configuration chain, such that fonts / users can still scale after this.

Thanks all for the discussion.  I think I have a way to do this that we can
all agree on.


> Raimund
Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux