Re: [HarfBuzz] Mai Kang Lai in Tai Tham, summary draft
I need to think about it and see how variation in positioning has been handled in other contexts, i.e. MYANMAR SIGN DOT BELOW in its positioning in Karen languages vs Burmese and Mon. Although I think the Tai Tham discussion and the way the fonts are evolving has already taken us to the stage where the fonts will be designed for Barfbuzz and will not render correctly on Uniscribe. Regarding the choice between solution one and solution two; are there examples of the positioning being contrastive, i.e. the same document using two or three of the differening conventions to mark distinctions between works? Or is it purely stylistic i.e. differing calligraphic and typographic conventions? If the difference is purely stylistic .. that leads us to solution 2. For solution 2 there seems to be two options: 1) fonts tailored for a specific typographic/stylistic convention; or 2) more typographically advanced fonts using graphite or opentype features to accommodate the variations, would it be possible to handle it as a variant glyph or stylistic set? I hope with a bit of spare time next week I can sit down and try experimenting with a minimal font, and see what could be done. Andrew On 21 May 2013 18:06, Theppitak Karoonboonyanan wrote: > On Tue, May 21, 2013 at 2:38 PM, Andrew Cunningham > wrote: > > > I'm wondering how much some of the detail is language based and may be > > handled using language systems? > > - Khuen: never shifted > - Lao: always shifted > - Lanna: any of the three (shifted, no shifted, conditionally shifted) > > However, all of these are "scripts" rather than "languages". > At least, both Lao Tham and Lanna Tham can be used to write Thai, > I suppose Khuen can, too. And all can be used to write Pali. > > Regards, > -- > Theppitak Karoonboonyanan > http://linux.thai.net/~thep/ > -- Andrew Cunningham Project Manager, Research and Development (Social and Digital Inclusion) Public Libraries and Community Engagement State Library of Victoria 328 Swanston Street Melbourne VIC 3000 Australia Ph: +61-3-8664-7430 Mobile: 0459 806 589 Email: acunning...@slv.vic.gov.au lang.supp...@gmail.com http://www.openroad.net.au/ http://www.mylanguage.gov.au/ http://www.slv.vic.gov.au/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-ucdn/ucdn.h | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) New commits: commit 601526392dec5d8432f147c91658ba50ed6a4322 Author: Behdad Esfahbod Date: Tue May 21 17:22:13 2013 -0400 Copy stdint.h boilerplate to ucdn diff --git a/src/hb-ucdn/ucdn.h b/src/hb-ucdn/ucdn.h index 802f044..381f70c 100644 --- a/src/hb-ucdn/ucdn.h +++ b/src/hb-ucdn/ucdn.h @@ -34,7 +34,29 @@ HB_BEGIN_HEADER -#include +#if !defined (HB_DONT_DEFINE_STDINT) + +#if defined (_SVR4) || defined (SVR4) || defined (__OpenBSD__) || \ +defined (_sgi) || defined (__sun) || defined (sun) || \ +defined (__digital__) || defined (__HP_cc) +# include +#elif defined (_AIX) +# include +/* VS 2010 (_MSC_VER 1600) has stdint.h */ +#elif defined (_MSC_VER) && _MSC_VER < 1600 +typedef __int8 int8_t; +typedef unsigned __int8 uint8_t; +typedef __int16 int16_t; +typedef unsigned __int16 uint16_t; +typedef __int32 int32_t; +typedef unsigned __int32 uint32_t; +typedef __int64 int64_t; +typedef unsigned __int64 uint64_t; +#else +# include +#endif + +#endif #define UCDN_EAST_ASIAN_F 0 #define UCDN_EAST_ASIAN_H 1 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Mai Kang Lai in Tai Tham, summary draft
On Tue, 21 May 2013 15:06:13 +0700 Theppitak Karoonboonyanan wrote: > On Tue, May 21, 2013 at 2:38 PM, Andrew Cunningham > wrote: > > I'm wondering how much some of the detail is language based and may > > be handled using language systems? > - Khuen: never shifted > - Lao: always shifted > - Lanna: any of the three (shifted, no shifted, conditionally shifted) > However, all of these are "scripts" rather than "languages". > At least, both Lao Tham and Lanna Tham can be used to write Thai, > I suppose Khuen can, too. And all can be used to write Pali. There's a sample of a 'recent' Tai Khuen printing of part of the Mangala Sutta on p241 of 'the History and Development of the Shan Scripts'. It has *shifted* mai kang lai! For the most part, the differences in style should match the intended audience, not the language of the content. Even so, I am not sure how one would use the language system to handle reordering issues. Is the suggestion that one might (ab)use language to decide on the reordering rules? For the 'mai kam' issue (if it cannot be resolved without reordering support - no-one's reported sorting out the rendering of using OpenType techniques), I suspect the relevant parameter is the degree of Bangkok influence. Richard. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Ligatures and color changes
On Tue, Feb 19, 2013 at 05:53:04PM -0500, Behdad Esfahbod wrote: > On 02/19/2013 05:47 PM, Khaled Hosny wrote: > > On Tue, Feb 19, 2013 at 05:34:40PM -0500, Behdad Esfahbod wrote: > >> As for *where* to cut the ligature, here's what you need: > >> > >> * Count the number of cursor positions *inside* the ligature. For the > >> "fi" > >> ligature it's one. And we have one cursor position before the ligature, > >> so in > >> this case we need to cut it in two pieces, > >> > >> * The common heuristic then is to cut the advance width of the ligature > >> (well, cluster really) into two equal pieces. If you want to be fancy, you > >> can call hb_ot_layout_get_ligature_carets(), and if the number of carets > >> matches what you expect (1 in this case I believe?), you can use the > >> returned > >> caret positions instead of equally dividing the ligature. I haven't seen > >> anyone implementing this though, as it gives very marginal improvements > >> over > >> the heuristic. > > > > It can make quite some different with some Arabic ligatures, but few > > fonts implement it because few (no?) engines support it :) > > Correct. Maybe you can give me a font... ;) OK, here is one :) https://github.com/khaledhosny/sahl-naskh > Note that BTW, a similar issue exists when kerning text. Most fonts implement > kerning by adjusting the advance width of the first glyph. What this means > however is that for a pair like "Te", if the e moves way under the T, > essentially we will get a very narrow selection width for the "T", and > unchanged width for the "e". That's less than ideal. > > In HarfBuzz we split the kerning half-and-half for old-style TrueType kern > pairs. But don't do something like that for GPOS kerning since, well, with > GPOS the font designer has full control on what to do. Maybe we should do the > same for GPOS kerning tables that only have adjustment for the first glyph and > not the second? Donno. May be a nice improvement. What do others think? I think it would be a good idea, that is the majority of LTR kerning anyway. Regards, Khaled ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Mai Kang Lai in Tai Tham, summary draft
On Tue, May 21, 2013 at 2:38 PM, Andrew Cunningham wrote: > I'm wondering how much some of the detail is language based and may be > handled using language systems? - Khuen: never shifted - Lao: always shifted - Lanna: any of the three (shifted, no shifted, conditionally shifted) However, all of these are "scripts" rather than "languages". At least, both Lao Tham and Lanna Tham can be used to write Thai, I suppose Khuen can, too. And all can be used to write Pali. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Mai Kang Lai in Tai Tham, summary draft
I'm wondering how much some of the detail is language based and may be handled using language systems? On 21/05/2013 5:31 PM, "Theppitak Karoonboonyanan" wrote: > On Tue, May 21, 2013 at 4:39 AM, Richard Wordingham > wrote: > > On Mon, 20 May 2013 15:08:19 +0700 > > Theppitak Karoonboonyanan wrote: > > > > For the recoding solution, you wrote: > > > > "A possible workaround is to exclude LA from the above rule. This is > > quite safe because NGA and LA are never conjoined in Pali grammar." > > > > While Pali doesn't have -ṅl- or -ṃl-, we do have Sanskrit influence > > to contend with. Thus, although Pali for 'masculine' is _pullinga_, the > > MFL lists ปุงลิงคะ with > > this meaning. Given the dictionary's spelling habits, I half expected to > > see MAI KANG LAI sitting on the BA. I don't think we can rely on MAI > > KANG LAI never sliding forward onto a LA. > > OK. The example implies that งฺล conjunct is still possible even in Pali. > So, I've removed the workaround from the text. > > The Unicode amendment may not help, either, as the use of MEDIAL LA > and side-subjoined LA is somewhat arbitrary. > > > If we're going to go for a coding solution, I'd rather go for a new > > character. However, out of ignorance, I have to ask - are non-shifted > > MAI KANG LAI and CONSONANT SIGN NGA different? Lao Tham suggests they > > might be the same thing. > > Yes, they are the same for Lao Tham. When used to write Pali, it's MAI > KANG LAI. When used to write Lao/Thai, it's FINAL NGA. But I heard > that the two are of different shapes in Khuen. So, they can't be used to > encode the same entity, I suppose. > > > Another conceivable solution you mention is, "Fonts for Lao Tham and > > the shifting school of Lanna may provide GSUB rule to reorder Mai Kang > > Lai themselves." > > > > This goes against what I first learnt about GSUB. I suppose it is > > tied up with how one handles editing of clusters of characters. > > Perhaps I'm just a semi-literate foreigner, but I frequently find > > myself having to edit 'legacy grapheme clusters'. It's helpful when > > the cursor actually shows me where I am within the cluster - but that > > can only be done if the connection between characters and glyphs is > > maintained. Using GSUB to change the order of characters destroys that > > information, which is why reordering is supposed to done by the > > script-specific shaping logic. > > Understood. I've added some text describing the problem. > > > I still haven't equipped myself to experiment with GPOS as a way of > > correcting the minor deficiencies of shaping. I'm about two weeks away > > at my current rate of progress. > > Let's add that to the page when you find some way out. > > > However, I think we are at a point where Behdad can say what he thinks > > of the 'rphf' option. > > Agreed. > > Regards, > -- > Theppitak Karoonboonyanan > http://linux.thai.net/~thep/ > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/harfbuzz > ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Mai Kang Lai in Tai Tham, summary draft
On Tue, May 21, 2013 at 4:39 AM, Richard Wordingham wrote: > On Mon, 20 May 2013 15:08:19 +0700 > Theppitak Karoonboonyanan wrote: > > For the recoding solution, you wrote: > > "A possible workaround is to exclude LA from the above rule. This is > quite safe because NGA and LA are never conjoined in Pali grammar." > > While Pali doesn't have -ṅl- or -ṃl-, we do have Sanskrit influence > to contend with. Thus, although Pali for 'masculine' is _pullinga_, the > MFL lists ปุงลิงคะ with > this meaning. Given the dictionary's spelling habits, I half expected to > see MAI KANG LAI sitting on the BA. I don't think we can rely on MAI > KANG LAI never sliding forward onto a LA. OK. The example implies that งฺล conjunct is still possible even in Pali. So, I've removed the workaround from the text. The Unicode amendment may not help, either, as the use of MEDIAL LA and side-subjoined LA is somewhat arbitrary. > If we're going to go for a coding solution, I'd rather go for a new > character. However, out of ignorance, I have to ask - are non-shifted > MAI KANG LAI and CONSONANT SIGN NGA different? Lao Tham suggests they > might be the same thing. Yes, they are the same for Lao Tham. When used to write Pali, it's MAI KANG LAI. When used to write Lao/Thai, it's FINAL NGA. But I heard that the two are of different shapes in Khuen. So, they can't be used to encode the same entity, I suppose. > Another conceivable solution you mention is, "Fonts for Lao Tham and > the shifting school of Lanna may provide GSUB rule to reorder Mai Kang > Lai themselves." > > This goes against what I first learnt about GSUB. I suppose it is > tied up with how one handles editing of clusters of characters. > Perhaps I'm just a semi-literate foreigner, but I frequently find > myself having to edit 'legacy grapheme clusters'. It's helpful when > the cursor actually shows me where I am within the cluster - but that > can only be done if the connection between characters and glyphs is > maintained. Using GSUB to change the order of characters destroys that > information, which is why reordering is supposed to done by the > script-specific shaping logic. Understood. I've added some text describing the problem. > I still haven't equipped myself to experiment with GPOS as a way of > correcting the minor deficiencies of shaping. I'm about two weeks away > at my current rate of progress. Let's add that to the page when you find some way out. > However, I think we are at a point where Behdad can say what he thinks > of the 'rphf' option. Agreed. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
