how to get internal font leading?
Vadim Zeitlin
While implementing (generic) markup rendering I realized that we don't
have access to a rather important piece of font information in wx API,
namely internal leading. wxDC::GetTextExtent() only returns the external
leading (inter-line interval) and descent (the size of the tail below the
baseline) but not the internal leading which is the size of the zone above
the normal letters top, i.e. in some sense symmetrical to descent.
This is important because when centering text vertically we need to take
into account "ascent - internal leading" height and while we have the
ascent (== "height - descent"), we don't have the internal leading. I
"approximated" it as being the same as descent in my code for now but this
is clearly wrong in general (although it happens to be right for some fonts
including the system Windows font under Windows 7 in its standard size...).
So I think it would be really better to implement support for getting the
internal leading directly. This would be trivial under Windows but I'm not
so sure about the other platforms. Could somebody more familiar with them
tell me whether we can retrieve this font metric under GTK/Pango and OS X?
Notice that they might (and probably do) call it differently as apparently
Microsoft terminology is different from the traditional typographical one.
Please see the drawing here
for the meaning that Windows uses for them and which I'd like to have
available in wx API.
Thanks,
VZ
iko...@earthlink.net
-----Original Message-----
>From: Vadim Zeitlin <va...@wxwidgets.org>
>Sent: Feb 22, 2011 7:46 AM
>To: wx-dev <wx-...@googlegroups.com>
>Subject: [wx-dev] how to get internal font leading?
>
> Hello,
>
> While implementing (generic) markup rendering I realized that we don't
>have access to a rather important piece of font information in wx API,
>namely internal leading. wxDC::GetTextExtent() only returns the external
>leading (inter-line interval) and descent (the size of the tail below the
>baseline) but not the internal leading which is the size of the zone above
>the normal letters top, i.e. in some sense symmetrical to descent.
>
Is this what you are looking for:
http://library.gnome.org/devel/pango/stable/pango-Fonts.html#pango-font-metrics-get-ascent
?
Thank you.
Vadim Zeitlin
> > While implementing (generic) markup rendering I realized that we don't
> >have access to a rather important piece of font information in wx API,
> >namely internal leading. wxDC::GetTextExtent() only returns the external
> >leading (inter-line interval) and descent (the size of the tail below the
> >baseline) but not the internal leading which is the size of the zone above
> >the normal letters top, i.e. in some sense symmetrical to descent.
> >
>
> Is this what you are looking for:
>
> http://library.gnome.org/devel/pango/stable/pango-Fonts.html#pango-font-metrics-get-ascent
>
> ?
Not sure but I don't think so. The ascent for Pango seems to mean the same
thing as for MSW, i.e. just "height - descent". I don't see anything on
this page that would correspond to the "leading" in the above sense
unfortunately.
Thanks for the link anyhow,
VZ
iko...@earthlink.net
-----Original Message-----
>From: Vadim Zeitlin <va...@wxwidgets.org>
As you mention MS does not confirm to the typographical standard. And you also mention
that it is symmetrical to the descent.
I can try to ask on the GTK+ list if someone more familiar with won't show up soon
or you won't try it out to test.
Thank you.
Slightly off-topic: I reply on the strikethrough ticket. Whenever you have a minute
can you look at that. I realize that my answers to the point 1 might be a little
confusing, but maybe we can figure something out to satisfy backward compatibility
and make some changes to the font construction code?
iko...@earthlink.net
-----Original Message-----
>From: Vadim Zeitlin <va...@wxwidgets.org>
>Sent: Feb 22, 2011 11:32 AM
>To: wx-...@googlegroups.com
>Subject: Re[4]: [wx-dev] how to get internal font leading?
>
>On Tue, 22 Feb 2011 11:23:43 -0800 (GMT-08:00) iko...@earthlink.net wrote:
>
>> > Not sure but I don't think so. The ascent for Pango seems to mean the same
>> >thing as for MSW, i.e. just "height - descent". I don't see anything on
>> >this page that would correspond to the "leading" in the above sense
>> >unfortunately.
>>
>> As you mention MS does not confirm to the typographical standard.
>
> This doesn't mean that the concept doesn't make sense though, just that
>it's (AFAIU) called differently elsewhere.
OK.
>
>> And you also mention that it is symmetrical to the descent.
>
> No, no, it's just a hack that I had to use. There is no reason for it to
>be the same as descent in general and this is not the case for many MSW
>fonts (even the standard font, which in normal size has descent = internal
>leading = 3, has descent = 6 and leading = 8 in xx-large size).
Then I misunderstood you. Because the way you said it it sounded that way.
>
>> Slightly off-topic: I reply on the strikethrough ticket. Whenever you
>> have a minute can you look at that. I realize that my answers to the
>> point 1 might be a little confusing, but maybe we can figure something
>> out to satisfy backward compatibility and make some changes to the font
>> construction code?
>
> I'll try to look at this again but for now I really want to finish my
>markup work.
OK, take you time. I'm at no rush.
>
> Regards,
>VZ
Vadim Zeitlin
> > Not sure but I don't think so. The ascent for Pango seems to mean the same
> >thing as for MSW, i.e. just "height - descent". I don't see anything on
> >this page that would correspond to the "leading" in the above sense
> >unfortunately.
>
> As you mention MS does not confirm to the typographical standard.
This doesn't mean that the concept doesn't make sense though, just that
it's (AFAIU) called differently elsewhere.
> And you also mention that it is symmetrical to the descent.
No, no, it's just a hack that I had to use. There is no reason for it to
be the same as descent in general and this is not the case for many MSW
fonts (even the standard font, which in normal size has descent = internal
leading = 3, has descent = 6 and leading = 8 in xx-large size).
> Slightly off-topic: I reply on the strikethrough ticket. Whenever you
> have a minute can you look at that. I realize that my answers to the
> point 1 might be a little confusing, but maybe we can figure something
> out to satisfy backward compatibility and make some changes to the font
> construction code?
I'll try to look at this again but for now I really want to finish my
markup work.
Regards,
VZ
Krishna
On Tue, Feb 22, 2011 at 9:16 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> Hello,
>
> While implementing (generic) markup rendering I realized that we don't
> have access to a rather important piece of font information in wx API,
> namely internal leading. wxDC::GetTextExtent() only returns the external
> leading (inter-line interval) and descent (the size of the tail below the
> baseline) but not the internal leading which is the size of the zone above
> the normal letters top, i.e. in some sense symmetrical to descent.
>
> This is important because when centering text vertically we need to take
> into account "ascent - internal leading" height and while we have the
> ascent (== "height - descent"), we don't have the internal leading. I
> "approximated" it as being the same as descent in my code for now but this
> is clearly wrong in general (although it happens to be right for some fonts
> including the system Windows font under Windows 7 in its standard size...).
> So I think it would be really better to implement support for getting the
> internal leading directly. This would be trivial under Windows but I'm not
> so sure about the other platforms. Could somebody more familiar with them
> tell me whether we can retrieve this font metric under GTK/Pango and OS X?
Donno whether it is useful. Factor's text rendering is documented in
[3], [2] and [1]. It uses CoreText's CTLineGetImageBounds() and
CTLineGetTypographicBounds(). I haven't used them myself -- merely
parroting.
[1] http://factor-language.blogspot.com/2009/02/font-metrics-and-baseline-alignment.html
[2] http://factor-language.blogspot.com/2009/02/metric-bounds-versus-image-bounds.html
[3] http://factor-language.blogspot.com/2009/01/rendering-unicode-text-to-opengl.html
--
The programmer is fighting against the two most destructive forces in
the universe: entropy and human stupidity.
--Damian Conway
Krishna
> Hello Vadim,
>
> On Tue, Feb 22, 2011 at 9:16 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
>> Hello,
>>
>> While implementing (generic) markup rendering I realized that we don't
>> have access to a rather important piece of font information in wx API,
>> namely internal leading. wxDC::GetTextExtent() only returns the external
>> leading (inter-line interval) and descent (the size of the tail below the
>> baseline) but not the internal leading which is the size of the zone above
>> the normal letters top, i.e. in some sense symmetrical to descent.
>>
>> This is important because when centering text vertically we need to take
>> into account "ascent - internal leading" height and while we have the
>> ascent (== "height - descent"), we don't have the internal leading. I
>> "approximated" it as being the same as descent in my code for now but this
>> is clearly wrong in general (although it happens to be right for some fonts
>> including the system Windows font under Windows 7 in its standard size...).
>> So I think it would be really better to implement support for getting the
>> internal leading directly. This would be trivial under Windows but I'm not
>> so sure about the other platforms. Could somebody more familiar with them
>> tell me whether we can retrieve this font metric under GTK/Pango and OS X?
>
> Donno whether it is useful. Factor's text rendering is documented in
> [3], [2] and [1]. It uses CoreText's CTLineGetImageBounds() and
> CTLineGetTypographicBounds(). I haven't used them myself -- merely
> parroting.
>
pango implementation is covered in [4].
[4] http://factor-language.blogspot.com/2009/03/rendering-unicode-text-with-pango-and.html
Stefan Csomor
what exactly goes wrong if you center the baselines ? or the middle of
ascent + descent ? I have found several calls, but non directly for the
internal leading
Best,
Stefan
Vadim Zeitlin
SC> what exactly goes wrong if you center the baselines ?
Centering the baseline is not the right thing to do as the text definitely
wouldn't be centered in the rectangle then (remember that I'm drawing the
label inside the button). Centering the entire rectangle of the height
equal to font height is more reasonable but this is not what Windows does
and if I do this the owner-drawn buttons using markup look differently (and
worse) compared to normal buttons. By looking at the offset it really seems
like Windows centers the rectangle of height equal to "ascent - leading"
and this makes sense: this is the "main part" of the character so the text
looks best if it is vertically centered (and accents and hanging parts of
the letters are outside of it).
SC> or the middle of ascent + descent ?
Unless I'm missing something this is exactly the same as simply centering
the rectangle of character height.
BTW, we could have avoided all this if we had the following 2 things in
our API:
1. The notion of current text position, i.e. DC coordinates that are used
for text output by default and updated after outputting the text.
2. The notion of text alignment, i.e. the relationship between the position
at which text output begins and the text itself. By default this is the
top left corner of the text but it is often (as in this case) useful to
change it to be the baseline instead.
Implementing this would be pretty simple for MSW because SetTextAlign()
(http://msdn.microsoft.com/en-us/library/dd145091(v=vs.85).aspx) but,
again, I don't know if other platforms support this.
SC> I have found several calls, but non directly for the internal leading
Do you know about CTLineGetTypographicBounds() mentioned in the other
reply? I'm not sure if it returns internal or external leading?
Thanks,
VZ
Vadim Zeitlin
K> Donno whether it is useful. Factor's text rendering is documented in
K> [3], [2] and [1]. It uses CoreText's CTLineGetImageBounds() and
K> CTLineGetTypographicBounds(). I haven't used them myself -- merely
K> parroting.
K>
K> [1] http://factor-language.blogspot.com/2009/02/font-metrics-and-baseline-alignment.html
K> [2] http://factor-language.blogspot.com/2009/02/metric-bounds-versus-image-bounds.html
K> [3] http://factor-language.blogspot.com/2009/01/rendering-unicode-text-to-opengl.html
Thanks for the links! CTLineGetTypographicBounds() definitely looks
interesting but I'm not sure whether the leading it returns is internal or
external one (i.e. inter-line distance).
For Pango there doesn't seem to be any direct way to get the internal
leading but the post [4] does provide a very obvious, in retrospect,
solution: just get the vertical extent of "Y" letter. This is probably not
completely universal, i.e. I guess there are some fonts where "Y" doesn't
take the full height but this should be pretty rare. So I guess I should
simply use this approach as a (better) approximation for now.
Thanks,
VZ
[4] http://factor-language.blogspot.com/2009/03/rendering-unicode-text-with-pango-and.html
Stefan Csomor
Am 23.02.11 12:10 schrieb "Vadim Zeitlin" unter <va...@wxwidgets.org>:
>Thanks for the links! CTLineGetTypographicBounds() definitely looks
>interesting but I'm not sure whether the leading it returns is internal or
>external one (i.e. inter-line distance).
external, as I said, there are currently no APIs calls anymore retrieving
Stefan Csomor
>Centering the baseline is not the right thing to do as the text definitely
>wouldn't be centered in the rectangle then (remember that I'm drawing the
>label inside the button). Centering the entire rectangle of the height
>equal to font height is more reasonable but this is not what Windows does
>and if I do this the owner-drawn buttons using markup look differently
>(and
>worse) compared to normal buttons. By looking at the offset it really
>seems
>like Windows centers the rectangle of height equal to "ascent - leading"
>and this makes sense: this is the "main part" of the character so the text
>looks best if it is vertically centered (and accents and hanging parts of
>the letters are outside of it).
and if we'd make sure that the x-height is at the same level ? this is
something I could retrieve ...
>2. The notion of text alignment, i.e. the relationship between the
>position
> at which text output begins and the text itself. By default this is the
> top left corner of the text but it is often (as in this case) useful to
> change it to be the baseline instead.
on mac it was the baseline, I always had to convert
Best,
Stefan
Vadim Zeitlin
SC> >By looking at the offset it really seems like Windows centers the
SC> >rectangle of height equal to "ascent - leading" and this makes sense:
SC> >this is the "main part" of the character so the text looks best if it
SC> >is vertically centered (and accents and hanging parts of the letters
SC> >are outside of it).
SC>
SC> and if we'd make sure that the x-height is at the same level ? this is
SC> something I could retrieve ...
I this this would work too. But OTOH I really wonder why not just do what
I wrote in my reply to Krishna and just center the "Y"-height, this should
work pretty well in practice. I just need to test this to verify that this
still results in the same positioning as in the standard buttons in wxMSW.
SC> >2. The notion of text alignment, i.e. the relationship between the
SC> >position at which text output begins and the text itself. By default
SC> >this is the top left corner of the text but it is often (as in this
SC> >case) useful to change it to be the baseline instead.
SC>
SC> on mac it was the baseline, I always had to convert
Baseline probably makes more sense by default actually but we really need
both (at least...) and a way to switch between them. And the current text
position is something that is pretty useful too, does Mac have this by
chance?
Regards,
VZ