Re: [HarfBuzz] hb-shape vs hb-view: ligatures
LS == Lars Schwarz lars.schw...@gmail.com writes: LS Example text I'm using is Sauerstoffflasche. The image shows glyphs for LS st, ff and fl, but hb-shape returns this: LS S,a,u,e,r,s,t,o,f_f,fl,a,s,c,h,e LS I was expecting something like 'st' instead of 's' and 't'? What font? I tried that with a couple of fonts, and had to pass --features=dlig to get the st lig. Passing --features=dlig also to hb-shape showed (for one font): [S=0+472|a=1+396|u=2+487|e=3+415|r=4+327|s_t=5+614|o=7+492|f_f=8+523|f_l=10+482|a=12+406|s=13+342|c_h=14+870|e=16+420] and, for DejaVu Serif: [S=0+1403|a=1+1221|u=2+1319|e=3+1212|r=4+979|uniFB06=5+1910|o=7+1233|uniFB00=8+1455|fl=10+1366|a=12+1221|s=13+1051|c=14+1147|h=15+1319|e=16+1212] The c_h lig only occurs with --language=de; but the s_t lig only requires --features=dlig. (I'm on hb 0.9.37, compiled from git.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] hb-shape vs hb-view: ligatures
LS == Lars Schwarz lars.schw...@gmail.com writes: LS Ok, that did the trick, nevertheless I'm still wondering what's the LS default behaviour for this (when omitting --features)? Seems like LS defaulting to something? The font's tables specify default behaviour for things like that. And hb applies a set of features by default. OTOH, the fact that, even without a zero-width non-joiner between Sauerstoff and flasche, it doesn't create a inter-compund lig is just co-incidence. Were one to use a font with an fff lig one probably would get fff l instead of ff fl. Likewise, with most fonts, if the first sub-word ended in a single f. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] telugu
BE == Behdad Esfahbod beh...@behdad.org writes: BE Can you rephrase the problem? Ie. what's the shortest Unicode sequence to BE reproduce it? What's expected / actual output? Which fonts? Based on the unicode@ post (I don’t speak or read any of the Dravidian langs/scripts), the problem is: ఽం U+0C3D U+0C02 where, except when using the font Pothana2000, hb and pango display an unwanted dotted circle before the U+0C02. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] tegulu
You probably saw this string today on unicode@: ।।ఓం పయోఽంబువచ్చేత్ తత్రాపి ఓం।। 3 hb-view from master and pango-view from 1.34.0 were able to render that w/o a dotted circle between the ఽం when I used Pothana2000. With every other font returned by fc-list :lang=te|sort they rendered a dotted circle between those two glyphs. Emacs, using libotf and m17n-lib, rendered it correcly. (Unlike hb-view, pango-view fell back for the four instances of ।. I presume that is by design.) For those who don't utf-8, that pair of chars is: u+0C3D TELUGU SIGN AVAGRAHA U+0C02 TELUGU SIGN ANUSVARA -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Support for optical 'opdb' feature(s)
A few years ago now¹, [sigh], a discussion which might have been on the opentype list concluded that this is the ideal algorithm for breaking a paragraph when using opentype features: 1) Characters - initial glyphs 2) GSUB 3) GPOS (kerning for non-OpenType) 4) Division into breakable syllables 5) Line break decision 6) Repeat steps 1-3, just once The opbd (and therefore ltbd and rtbd) lookups should occur as part of step five. -JimC 1] About 4½ years ago, based on the file where I found my notes -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] does graphite affect the c++ munging? Does -On?
[Background for the harfbuzz readers: hb fails to compile with icu 50_rc and gcc 4.7.2 with an inconsistancy between what icu provides for LEFontInstance::mapCharsToGlyphs() and that hb wants.] PT == Philipp Thomas philipp.thom...@gmx.net writes: PT For me it looks like the header doesn't match the library. I looked again in case I missed anything last night. /usr/include/layout/LEFontInstance.h has: virtual void mapCharsToGlyphs(const LEUnicode chars[], le_int32 offset, le_int32 count, le_bool reverse, const LECharMapper *mapper, le_bool filterZeroWidth, LEGlyphStorage glyphStorage) const; icu(-50_rc)/source/layout/LEFontInstance.cpp has: LEFontInstance::mapCharsToGlyphs(const LEUnicode chars[], le_int32 offset, le_int32 count, le_bool reverse, const LECharMapper *mapper, le_bool filterZeroWidth, LEGlyphStorage glyphStorage) const /usr/lib/libicule.so provides: _ZNK3icu14LEFontInstance16mapCharsToGlyphsEPKDsiiaPKNS_12LECharMapperEaRNS_14LEGlyphStorageE which c++filt expands to: icu::LEFontInstance::mapCharsToGlyphs(char16_t const*, int, int, signed char, icu::LECharMapper const*, signed char, icu::LEGlyphStorage) const But hb's libhb_icu_le_la-PortableFontInstance.o wants: _ZNK3icu14LEFontInstance16mapCharsToGlyphsEPKtiiaPKNS_12LECharMapperEaRNS_14LEGlyphStorageE which c++filt expands to: icu::LEFontInstance::mapCharsToGlyphs(unsigned short const*, int, int, signed char, icu::LECharMapper const*, signed char, icu::LEGlyphStorage) const It seems that icu's LEUnicode typedef is converted differently. And, to make it harder to debug, hb doesn't call mapCharsToGlyphs() at all. nm(1) finds it in the .o file, but objdump -d does not. I tried adding -dM -E to the g++ invocation hb uses for that file and found: #define U_HAVE_CHAR16_T 0 #define __CHAR16_TYPE__ short unsigned int which might have something to do with the different munging. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] [PATCH 1/1] [blob] Fix the initialization order
The fields were initialized out of order, causing a cast from
NULL to unsigned int and a cast from 0 to a pointer.
Signed-off-by: James Cloos cl...@jhcloos.com
---
src/hb-blob.cc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/hb-blob.cc b/src/hb-blob.cc
index 58d7324..b2b1d9c 100644
--- a/src/hb-blob.cc
+++ b/src/hb-blob.cc
@@ -64,8 +64,8 @@ static hb_blob_t _hb_blob_nil = {
TRUE, /* immutable */
- 0, /* length */
NULL, /* data */
+ 0, /* length */
HB_MEMORY_MODE_READONLY, /* mode */
NULL, /* user_data */
--
1.7.6.1
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] harfbuzz coordinate system
BE == Behdad Esfahbod beh...@behdad.org writes: BE I'm wondering, should increasing y move upwards, or downwards? Most BE graphics API I've seen (PS-based API being the only exception) has y BE moving downward. I find that more intuitive in a text layout BE library, so we can say: in-line glyphs are stacked in the BE increasing x direction, lines are stacked in the increasing y BE direction. I've always thought of y going up w/in a font. It would be weird for the capsheight to be negative and descender depth to be positive. Especially since everything else has -ve descenders and +ve ascenders. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
