info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Does Tk text widget support ligatures?
102 views
Skip to first unread message
Dave
Jul 13, 2015, 11:45:11 PM7/13/15
to
From the very little I've googled, it appears that ligature info (if
supported by a particular font) is somehow embedded into a
font--especially for some non-English languages. There are apparently a
hand-full of ligatures defined for English unicode?
\ufb00 thru \ufb06 is ff, fi, fl, ffi, ffl, ft and st
Perhaps that's it.
If I attempted to implement the above, but the font did not have the
glyphs for some or all of the range fb00-fb06, is there a way I could tell?
--
computerjock AT mail DOT com
supported by a particular font) is somehow embedded into a
font--especially for some non-English languages. There are apparently a
hand-full of ligatures defined for English unicode?
\ufb00 thru \ufb06 is ff, fi, fl, ffi, ffl, ft and st
Perhaps that's it.
If I attempted to implement the above, but the font did not have the
glyphs for some or all of the range fb00-fb06, is there a way I could tell?
--
computerjock AT mail DOT com
Dave
Jul 19, 2015, 2:20:50 PM7/19/15
to
ligatures? No.
If there is a way to detect missing glyphs from a font, I would like to
know how. That would allow me to support \ufb06... if the font contained
that range.
Harald Oehlmann
Jul 20, 2015, 5:08:36 AM7/20/15
to
Tk will search all fonts and show missing glyphs in a font where it is available.
I don't know of any way to find out which font is finally used.
You may try this by:
pack [label .l2 -text A\ufb06B]
On my Windows 8.1, the used font for the Liglature just looks messy...
I don't know of any way to find out which font is finally used.
You may try this by:
pack [label .l2 -text A\ufb06B]
On my Windows 8.1, the used font for the Liglature just looks messy...
Arjen Markus
Jul 20, 2015, 5:27:33 AM7/20/15
to
Op maandag 20 juli 2015 11:08:36 UTC+2 schreef Harald Oehlmann:
Out of curiosity, I tried it on my Windows 7 machine too. The glyph that appeared looks like an s and t connected with a thin arc. What is it supposed to be?
Regards,
Arjen
Regards,
Arjen
Andreas Leitgeb
Jul 20, 2015, 5:40:06 AM7/20/15
to
Arjen Markus
Jul 20, 2015, 6:03:28 AM7/20/15
to
Op maandag 20 juli 2015 11:40:06 UTC+2 schreef Andreas Leitgeb:
Oh, that is a new one to me - I knew the ff, ffi etc. ligatures. In that case it looks decent enough (apart from the arc).
Regards,
Arjen
Oh, that is a new one to me - I knew the ff, ffi etc. ligatures. In that case it looks decent enough (apart from the arc).
Regards,
Arjen
Christian Gollwitzer
Jul 20, 2015, 7:35:52 AM7/20/15
to
Am 20.07.15 um 12:03 schrieb Arjen Markus:
The arc is correct. The original use case for th st ligature is with a
long s, the historic form of a lowercase s that looks similar to an f
without the crossing bar. This can be bound to a t in a similar way than
an f in ft. With the round lowercase s used everwhere now, the ligature
was reinvented as an s with a t which are bound together at the top by
an arc. The exact rendering, as usual, depends on the font (if it
supports the ligature at all). With the OpenType file format, additional
arbitrary combinations are possible, too, which can't even be addressed
as a unicode char. Personally I think that the ligatures in unicode are
a mistake, they should have been just in the display part of the fonts.
Christian
long s, the historic form of a lowercase s that looks similar to an f
without the crossing bar. This can be bound to a t in a similar way than
an f in ft. With the round lowercase s used everwhere now, the ligature
was reinvented as an s with a t which are bound together at the top by
an arc. The exact rendering, as usual, depends on the font (if it
supports the ligature at all). With the OpenType file format, additional
arbitrary combinations are possible, too, which can't even be addressed
as a unicode char. Personally I think that the ligatures in unicode are
a mistake, they should have been just in the display part of the fonts.
Christian
Harald Oehlmann
Jul 20, 2015, 8:22:45 AM7/20/15
to
I am also your opinion.
Within Windows, you may render a string with or without ligatures, depending on the parameters.
We may have a "ligature" patch one day.
Within Windows, you may render a string with or without ligatures, depending on the parameters.
We may have a "ligature" patch one day.
Dave
Jul 20, 2015, 12:14:26 PM7/20/15
to
I ran the following script:
package require Tk
frame .f -width 1200 -height 200
set LABEL [label .f.label -textvariable V]
set BUTTON [button .f.next -text Next -command {set Next clicked}]
pack .f.label -side top
pack .f.next -side bottom
pack propagate .f false
pack .f
foreach fam [font families] {
font create F -family $fam -size 36
set V "$fam: |\ufb00|\ufb01|\ufb02|\ufb03|\ufb04|\ufb05|\ufb06|"
$LABEL config -font F
set Next ""
tkwait variable Next
font delete F
}
$BUTTON config -text Quit
set Next ""
tkwait variable Next
exit
What I see is that >apparently< all the fonts render the above unicode
characters. However if I look closely, all of the glyphs are not the
same style for some fonts. I am guessing that when Tk finds that a
unicode glyph is missing in a font, it substitutes (for that glyph only)
a font that contains the glyph. Either that or windows is doing some
sort of substitution.
You can see this if you click "Next" and examine the \ufb06 glyph. Many
times it remains unchanged even when some of the other glyphs do.
Harald Oehlmann
Jul 21, 2015, 2:10:10 AM7/21/15
to
Am Montag, 20. Juli 2015 18:14:26 UTC+2 schrieb Dave:
> What I see is that >apparently< all the fonts render the above unicode
> characters. However if I look closely, all of the glyphs are not the
> same style for some fonts. I am guessing that when Tk finds that a
> unicode glyph is missing in a font, it substitutes (for that glyph only)
> a font that contains the glyph. Either that or windows is doing some
> sort of substitution.
This is Tk, not Windows. Windows would disblay a square box for missing characters. And it is as you write. Fonts are chosen glyph by glyph.
> What I see is that >apparently< all the fonts render the above unicode
> characters. However if I look closely, all of the glyphs are not the
> same style for some fonts. I am guessing that when Tk finds that a
> unicode glyph is missing in a font, it substitutes (for that glyph only)
> a font that contains the glyph. Either that or windows is doing some
> sort of substitution.
This is also the case for Unix.
-Harald
Donal K. Fellows
Jul 22, 2015, 9:44:13 AM7/22/15
to
On 14/07/2015 04:45, Dave wrote:
> There are apparently a hand-full of ligatures defined for English unicode?
It's usual to leave detection of whether to use ligatures to the
> There are apparently a hand-full of ligatures defined for English unicode?
rendering engine, not encode that in the logical level of the text.
However, I think we only really stand a chance to get that right on OSX
because there the text rendering engine gets to see more of the
characters at once than on the other platforms. (It's all horribly
complicated inside there.)
It matters much more for Arabic text than for Latin (English, French,
German, etc.) as you *cannot* render Arabic correctly without doing
ligature handling.
Donal.
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.
0 new messages