Behdad,
given that there is zero documentation in harfbuzz, and your
whitepaper
http://lists.freedesktop.org/archives/harfbuzz/2009-August/000359.html
is three years old while harfbuzz has evolved a lot meanwhile, I
wonder where I should start. (BTW, you should temporarily add the
above
In case these are prerequisites, it should be mentioned somewhere.
Yes, here's a much simpler thing:
https://github.com/anoek/ex-sdl-cairo-freetype-harfbuzz
Nice, thanks!
Lets just say that I hate gobject-introspection religiously...
Why are you going to use it, then?
Hope that
Yes, here's a much simpler thing:
https://github.com/anoek/ex-sdl-cairo-freetype-harfbuzz
Nice, thanks!
I had to patch the package with the attached diff (which also contains
some beautifications). Could someone tell me whether the changes are
correct? The output looks identical,
After doing a simple ./autogen.sh; make, with only
checking for FREETYPE... yes
and all other packages (GLIB, GTHREAD, etc.) returning `no', I get the
following errors while creating libharfbuzz.dll.a:
hb-ot-shape.cc:603: undefined reference to `__chkstk_ms'
harfbuzz-indic.cpp:1199:
hb-ot-shape.cc:603: undefined reference to `__chkstk_ms'
harfbuzz-indic.cpp:1199: undefined reference to `__chkstk_ms'
This is minGW; gcc version 4.5.2.
Interesting. How do you invoke configure?
Via ./autogen.sh, with no arguments.
Where did you get your FreeType binary from?
I
In HarfBuzz we override the linker to use a C linker, not C++, and
we don't link with libstdc++. This works with GCC and mingw on
Linux. Not sure on Windows. Try overriding the linker. Ie. remove
this line from src/Makefile.am:
libharfbuzz_la_LINK = $(LINK) $(libharfbuzz_la_LDFLAGS)
Behdad,
I suggest the fix below. The old text was incorrect (the first
`Value' value must be 0, not 1), and using `aalt' instead of `kern' is
probably more meaningful.
Werner
==
diff --git a/util/options.cc
[commit 9947bd6d]
Behdad,
I have forgotten what exactly `hb-ot-shape-closure' does, and I had to
look it up in the internet. Maybe you can add a few words to the
output of `--help', something like
http://lists.freedesktop.org/archives/harfbuzz/2012-May/001945.html
Testing with TeX Gyre
It seems that something is broken in the current git version of
harfbuzz...
Oops. My bad. Fixed. Sorry!
Thanks for the quick fix.
Werner
PS: Any progress on the coverage stuff?
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
For what it's worth Jonathan and I looked into this in Vancouver and
tracked it down to hb-ft's abuse of FreeType API with disregard to
hinting issues. I'll try to address it soonish...
Anything affecting me?
Werner
___
HarfBuzz mailing list
I don’t think there are existing JSON to TeX packages, but it
shouldn’t be hard to write some python script to process JSON output
(I’m guessing here, I never dealt with JSON).
pandoc?
Werner
___
HarfBuzz mailing list
I've finally gotten around to experimenting with this in Firefox,
and run into a couple of issues that mean it doesn't quite work
as-is: [...]
Thanks for trying! I'll start with using HarfBuzz in a few weeks or
so, thus I'm glad that I'm not the very first beta-tester :-)
Werner
Here:
https://github.com/lxnt/ex-sdl-freetype-harfbuzz
Is a variant that does not depend on Cairo, glib or ICU.
Very nice!
The origin at
https://github.com/anoek/ex-sdl-cairo-freetype-harfbuzz has a nasty
bug in that it tries to set font point size with a double instead of
Freetype's
I think this was yet another tremendously productive week of
pair-programming with Jonathan, and would like to thank him for
finding them time to make this happen. I also like to thank Martin
Hosken, whose expertise in the scripts covered in this hackfest was
key to making progress that we
Behdad,
please, PLEASE add some documentation to harfbuzz! It really drives
me crazy that I have to read the source code of harfbuzz to get some
clues. This is an endless time sink :-(
While the source code is written very cleanly, the purpose of it is
not as obvious as you might think. For
Lemme try to answer some of your questions from my very limited
knowledge until Behdad responds.
Thanks! I think my main problem is that I've never used Cairo.
Otherwise, a lot of concepts would be immediately clear to me, I
believe.
For example, what's the difference
between
With no further comments, lets get to the list of changes I like to
discuss: [...]
Unfortunately, my knowledge of HarfBuzz is (yet) too limited to give
useful comments. However, I'm wondering whether the yet-to-come
splitting of HarfBuzz into two or more libraries does affect the API.
BTW,
[harfbuzz 0.9.25]
Please tell me why the attached program returns zero and not true.
In font `pala.ttf' (version 5.00), GSUB lookup 1 (part of the `smcp'
feature) maps glyph `f' to glyph 1107, so there is definitely a
substitution. However, `hb_ot_layout_lookup_would_substitute' returns
zero,
Doh. Thanks, it works now. It's *really* time that HarfBuzz gets
documented :-)
That's definitely true. But Werner, you being FreeType maintainer
of over a decade, I don't agree with you this time. *You* should
know that a parameter called glyphs takes glyph indices, not
Unicode
So my question is: what type of documentation do people in the list
want to see the most? In-line function docs in the comments that
populate the gtk-docs?
Each function needs a description, together with an explanation of all
parameters, return values, etc., etc. – just think of having a
Behdad,
since the introduction of gtk-doc support it's no longer easy to
compile harfbuzz from the git under MinGW. Any idea to make this work
again? Ideally, `autogen.sh' should emit a warning if gtkdocize can't
be found, not abort, then disable the creation of documentation.
I've found
Using MinGW's gcc compiler version 4.8.1, I get the following
compilation error of HarfBuzz 0.9.26:
CXX libharfbuzz_la-hb-common.lo
In file included from hb-object-private.hh:37:0,
from hb-common.cc:32:
hb-common.cc: In function 'hb_language_item_t*
hb-common.cc: In function 'hb_language_item_t* lang_find_or_insert(const
char*)':
hb-atomic-private.hh:61:47: error: expected primary-expression before ')'
token
#define hb_atomic_ptr_get(P) (MemoryBarrier (), (void *) *(P))
Interesting. Can you try the attached patch? Looks like a
since the introduction of gtk-doc support it's no longer easy to
compile harfbuzz from the git under MinGW. Any idea to make this
work again? Ideally, `autogen.sh' should emit a warning if
gtkdocize can't be found, not abort, then disable the creation of
documentation.
It's not quite
Ha! I'm doing all the work on a real Win7 box, so this option
doesn't work.
Ah, why would you inflict such pain on yourself?
:-) When I'm grown up, I'll buy a computer that has enough memory and
speed for a virtual box...
Note that I can still build a tarball on my GNU/Linux box, then
Behdad,
a minor patch.
Werner
==
diff --git a/src/hb-ucdn/Makefile.am b/src/hb-ucdn/Makefile.am
index 40d6055..0670b5c 100644
--- a/src/hb-ucdn/Makefile.am
+++ b/src/hb-ucdn/Makefile.am
@@ -7,7 +7,7 @@
[libtool 2.4.2]
I'm compiling harfbuzz under OS X 10.7.5 (i.e., Darwin 11.4.2), XCode
4.6.3 (i.e., i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1), with the
following configuration flags; see attached build script for more.
--enable-static
LDFLAGS=CFLAGS=CXXFLAGS=-arch i386 -arch x86_64
Compiling with -ansi using
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1
(Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
I get the following warning:
hb-common.h:280: warning:
ISO C restricts enumerator values to range of 'int'
Nothing really serious, but probably worthwhile
Folks,
I just want to give a heads-up that FreeType now links to HarfBuzz
even in non-devel mode; by default, it links only to it if it can be
found. In case both FreeType and HarfBuzz need to be installed, you
have to first install FreeType, then HarfBuzz, then FreeType again.
Would be nice
This in turn brought this idea: we should amalgamate FreeType and
HarfBuzz,
Hmm. From a conceptual point of view, FreeType is definitely at a
lower level than most of HarfBuzz. Splitting HarfBuzz into two parts
and amalgate the non-high-level part with FreeType is fine with me.
After that,
Not really... It's perfectly legitimate to use non-existing glyph
indices as interim number during GSUB...
Just curious: Have you actually tested this behaviour with
existing engines?
When in doubt, do your own check.
OK.
In this case, it's probably a font bug. But I don't think we want
hb-common.cc: In function 'hb_language_item_t* lang_find_or_insert(const
char*)':
hb-atomic-private.hh:61:47: error: expected primary-expression before ')'
token
#define hb_atomic_ptr_get(P) (MemoryBarrier (), (void *) *(P))
The good news: Your patch works :-) To avoid warnings, you
since the introduction of gtk-doc support it's no longer easy to
compile harfbuzz from the git under MinGW. [...]
I tried to fix this with the commit I just pushed out. Please test.
I've just tested the current git, and it works OK. Thanks!
Werner
After that you should recompile FreeType again [...]
Uh, oh, I mean either `compile again' or `recompile' :-)
Werner
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Behdad,
is there any way in HarfBuzz to access the glyph indices in
MarkCoverage and BaseCoverage tables? Or Coverage tables in general?
Problem: For ttfautohint, I need all GSUB glyphs that aren't shifted
in GPOS.[*] Right now, I simply subtract the GPOS set from the GSUB
set; this works
is there any way in HarfBuzz to access the glyph indices in
MarkCoverage and BaseCoverage tables? Or Coverage tables in
general? [...]
After some thinking I guess that data in the GDEF table will serve, at
least right now :-) I solved the problem differently, so it is not an
issue for me
However, there are more GSUB lookups, referenced via chained
context lookups, AFAICS. Example: lookup 76, which gets referenced
in lookup 4.
I presume that this is not intentional behaviour.
It *is* intentional behavior. What's your exact use case?
Actually, I don't really care about
However, I see that the mapping result of lookup 76, `glyph242', is
part of the set returned by `hb_ot_layout_lookup_collect_glyphs', so
everything's' fine. Sorry for the noise.
Well, I've now taken a look at `mangal.ttf' (version 5.91 from
Windows 7), and I get *a lot* of glyphs not covered
Well, I've now taken a look at `mangal.ttf' (version 5.91 from
Windows 7), and I get *a lot* of glyphs not covered by
`hb_ot_layout_lookup_collect_glyphs', which is really bad for me.
[...]
Found my error. Again sorry for the noise.
Werner
Originally I wanted to change hb_ft_face_create() and
hb_ft_font_create() to reference the face if destroy==NULL was
passed in. That would improve pretty much all clients, with
little undesired effects. Except that FreeType itself, when
compiled with HarfBuzz support,
I also see that freetype is required by Qt and this call some
functionality of harfbuzz to render thai fonts correctly.
???
Does Qt uses the freetype libraries (libfreetype.so). If yes can I
build freetype --with-harbuzz so that Qt will use harfbuzz-0.9.38.
Is this a correct way?
No.
I disabled the FreeType dependency for now. Will re-enable in a
year or two. Was too lazy to file a bug against Ubuntu 14.04 re
shipping ancient pkg-config...
This probably deserves an entry in the HarfBuzz documentation – oops,
there still isn't one :-)
Werner
Behdad,
it seems to me that harfbuzz.pc returns incorrect values for static
linking. Building and installing current git using `configure
--enable-static' I get
$ pkg-config --libs --static harfbuzz
-L/usr/local/lib -lharfbuzz
which obviously misses FreeType...
Werner
Should be fixed in master. On my machine pkg-config crashes if
I specify --static. Please test.
For me it works, thanks!
Oh, I suppose it doesn't like the recursive dependency between
HarfBuzz and FreeType... You'd think pkg-config knows how to deal
with circular deps. Looks like
>> Knuth knew *very well* what he was doing, and the TeX typesetting
>> model works just fine for almost all cases, even more than 30 years
>> later.
>
> That is such a big claim, judging by the amount of people strugling with
> TeX line spacing on tex.stackexchange.com:
>
>> Ok, so I've patched hb-ft to allow setting load_flags. Here's a
>> branch:
>>
>> https://github.com/behdad/harfbuzz/commit/ce981bdc6f58f390af4bee575500ffc45a877ab6
>
> Thanks! Do you already have a patch for hb-view?
Ping :-)
Werner
___
> Ok, so I've patched hb-ft to allow setting load_flags. Here's a
> branch:
>
> https://github.com/behdad/harfbuzz/commit/ce981bdc6f58f390af4bee575500ffc45a877ab6
Thanks! Do you already have a patch for hb-view?
> However, now I see that you are mostly asking about rendering
> options...
[Resending, now that Behdad is back from Iran :-)]
Folks,
how can I locally enforce TrueType bytecode rendering for hb-view? A
command line option? An environment setting?
Werner
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
> how can I locally enforce TrueType bytecode rendering for hb-view?
> A command line option? An environment setting?
I've looked up the code, and it seems that this is hard-coded in
hb-view. Behdad, can you make this configurable? Maybe allowing the
user to pass (some) FT_LOAD_XXX flags as a
> It seems to me that the best way to do this is just to provide one
> .cpp file that just includes everything else. [...]
Cf.
https://github.com/vinniefalco/FreeTypeAmalgam
https://github.com/vinniefalco/Amalgams/
Werner
___
HarfBuzz
[harfbuzz 1.3.3]
Behdad,
attached you can find a fuzzed font that exhibits very bad behaviour
of `hb_ot_layout_lookup_collect_glyphs': it iterates a few billion
times while looking up data for `mlym', which is certainly invalid
behaviour.
I've run `ftfuzzer' with
valgrind --tool=callgrind
> attached you can find a fuzzed font that exhibits very bad behaviour
> of `hb_ot_layout_lookup_collect_glyphs': [...]
This is now
https://github.com/behdad/harfbuzz/issues/363
so that it won't be forgotten.
Werner
___
HarfBuzz mailing list
Hello Dominik!
> We have a Chromium issue where the text "We'll email the promo code
> to you. Enter it in your cart to apply" renders wider after FreeType
> commit bcc74f4dafee25e [truetype] Allow linear scaling for unhinted
> rendering (#50470). - I have not exactly identified in which way it
>> PS. Sometime I think about shutting down the list and using github
>> exclusively. What do people think?
>
> If github is meant to be for issues with HarfBuzz, then the list is
> useful for where the issue may well be with the user rather than the
> package.
Exactly. Use questions should
>> I know I asked this before but... is there still value in keeping
>> the list around? I find myself preferring github issues over
>> mailing list threads all the time.
I prefer e-mail lists. Assuming that I'm interested in general
HarfBuzz issues, I had to activate github tracking of all
>> Shouldn't hb_script_from_iso15924_tag map "Hans" and "Hant" to
>> HB_SCRIPT_HAN?
>
> hb_script_from_iso15924_tag() doesn't do any mapping whatsoever.
>
> Why is that desirable?
>
> [I find it really weird using mailing lists, as opposed to github
> issues, these days.]
Really? For simple
56 matches
Mail list logo
