On 19/08/2020 19:44, Richard Wordingham wrote:
On Wed, 19 Aug 2020 20:09:51 +0300
Eli Zaretskii wrote:
Could someone please look at the discussion and the data of the Emacs
bug#34035 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34035) and
tell whether the fonts that produce incorrect display
On 13/07/2020 17:45, Eli Zaretskii wrote:
Cc: harfbuzz@lists.freedesktop.org
From: Phil M Perry
Date: Mon, 13 Jul 2020 11:11:51 -0400
Eli, I realize that (except for Chinese, Japanese, and possibly Korean),
text is normally written horizontally (LTR or RTL). Vertical text is for
special uses su
On 14/02/2020 15:50, Aleš Mlakar wrote:
Hey Simon,
I think it doesn't use rand feature, because it never gets to that part
of the code or at least not to the random_number() function which is the
only rng function I could find in Harfbuzz :D.
HarfBuzz will only use this if the font has a 'ran
If the font you're talking about is
https://www.myfonts.com/fonts/pintassilgo/daft-brush?tab=techSpecs, then
it does claim to include a 'rand' feature.
I don't know how InDesign attempts to use 'rand' (if at all), but given
the description of the feature in
https://docs.microsoft.com/en-gb/ty
On 03/06/2019 14:46, Vijendra Singh wrote:
Hi All,
I am using HarfBuzz 2.10 for Indic languages in my application but
failed to get correct substituted glyph from hb_shape API for Bengali
text having vowels like e (U+09c7), ai (U+09c8), o (U+09cb), au (U+09cc)
in between the words in any Bang
On 11/05/2019 20:38, Eli Zaretskii wrote:
Cc: Behdad Esfahbod ,
"harfbuzz@lists.freedesktop.org"
From: Jonathan Kew
Date: Sat, 11 May 2019 20:11:17 +0100
Yes. The font file. Maybe describe what you are trying to do?
If you've got access to the font as a file or as a s
On 11/05/2019 19:51, Behdad Esfahbod wrote:
On Sat, May 11, 2019 at 11:50 AM Eli Zaretskii <mailto:e...@gnu.org>> wrote:
> From: Behdad Esfahbod mailto:beh...@behdad.org>>
> Date: Sat, 11 May 2019 11:38:58 -0700
> Cc: Jonathan Kew m
On 11/05/2019 10:39, Eli Zaretskii wrote:
Is it possible to create a hb_face_t without going through Freetype?
If so, could someone please tell what that would entail?
You can use hb_face_create_for_tables, passing it a function that can
retrieve font tables (as hb_blobs) when requested by har
On 10/04/2019 20:19, Paul Daughetee wrote:
Let me give you a little more info. I just recently built and installed
vcpkg and used it to install HarfBuzz on Windows 10. It installed
version 2.3.1-3 of the static libraries for Window x86. I linked my app
to the HarfBuzz library and its dependenci
1/14/18, 2:23 AM, "HarfBuzz on behalf of Jonathan Kew"
wrote:
On 14/11/2018 05:54, Vijendra Singh wrote:
> Hi All,
>
> I am using HarfBuzz 2.10 for Indic languages in my application but
> failed to get correct substituted glyph for half “र” fro
On 14/11/2018 05:54, Vijendra Singh wrote:
Hi All,
I am using HarfBuzz 2.10 for Indic languages in my application but
failed to get correct substituted glyph for half “र” from hb_shape API
for Myriad Devanagari font even proper glyph (प्र) is available in the font.
e.g.प्रदेश () where as it
On 15/06/2018 15:53, Nathan Willis wrote:
It seems like this it what is used (the same regexps being used for all
scripts in HarfBuzz's Indic shaper):
matra_group = z{0,3}.M.N?.(H | forced_rakar)?;
[...]
halant_or_matra_group = (final_halant_group | (H.ZWJ)? matra_group{0,4});
... and that on
On 06/12/2017 09:34, Jani Brezavšček wrote:
Hello,
I'm writing because I can't find a solution to my problem.. I would like
to display the following hindi text as it is written bellow or e.g. in
google search bar
शक्ति (I put it in google translate and it looks like it means "power" in
hind
On 10/08/2017 05:43, Martin Hosken wrote:
Dear Behdad,
- if (buffer == NULL)
+ if (!buffer)
Always wanting to learn. How does this cause a divide by zero? Or what led you
to make the change?
It doesn't, that's purely stylistic. The real change in this commit
comes later on:
const
On 7/4/16 04:36, Martin Hosken wrote:
Dear All,
I meant 1.2.3 and 1.2.4 are broken.
I may be wrong, but my understanding is that this error came in with revision:
9a13ed453ef96822a47d6e6f58332b87f38d5c59 which was released with 1.2.1.
So it may be a bit wider than that. I don't think androi
On 5/4/16 20:17, Behdad Esfahbod wrote:
On Mon, Apr 4, 2016 at 9:11 PM, Martin Hosken mailto:mhos...@gmail.com>> wrote:
Dear Behdad,
> Ouch. I broke them in February (1.2.23 and .24 are broken). I'm fixing
> now.
I meant 1.2.3 and 1.2.4 are broken.
Do you know if these vers
On 24/2/16 16:41, Behdad Esfahbod wrote:
Thanks Jonathan. Somehow that Mozilla bug escaped my attention for five
years!
I'll add code to reject GDEF table based on its length and glyph class
of doublequote. Do you have any more blacklisted tables like that in
Firefox?
Oh, another one is Droi
On 24/2/16 16:41, Behdad Esfahbod wrote:
Thanks Jonathan. Somehow that Mozilla bug escaped my attention for five
years!
I'll add code to reject GDEF table based on its length and glyph class
of doublequote.
IIRC, this affects the BoldItalic as well as Italic; not sure if the
tables are ident
On 24/2/16 16:41, Behdad Esfahbod wrote:
Thanks Jonathan. Somehow that Mozilla bug escaped my attention for five
years!
I'll add code to reject GDEF table based on its length and glyph class
of doublequote. Do you have any more blacklisted tables like that in
Firefox?
See https://bugzilla.m
On 24/2/16 02:25, Behdad Esfahbod wrote:
Hi Jonathan,
As you probably know, I changed mark zeroing from BY_UNICODE_LATE to
BY_GDEF_LATE in HarfBuzz. So far I only got a bug report about Cantarell
breaking, which was fixed in the font's GDEF table.
Today, Dominik and I noticed that Times New Ro
On 6/1/16 14:17, Behdad Esfahbod wrote:
On 16-01-05 09:17 PM, Jamie Dale wrote:
I actually just wrote something to give me very similar information since I
realised that my basic "this is a ligature" flag wasn't enough data, so each
of my glyphs now contains the number of characters that the gly
On 10/12/15 11:08, Werner LEMBERG wrote:
What's the easiest solution to find out whether a character (or
character cluster) gets handled by a feature?
The only way I'm aware of to solve this is to call `hb_shape' twice,
with and without activating the feature, then comparing the resulting
glyph
ly not used for anything AFAIK. I don't know how
the implementation will look like, but it's definitely possible to tell, eg,
JNN developers, to give the blank glyph a GDEF class of Component...
WDYT?
Without having tried to think it through in detail, that sounds like a
promis
Behdad: re this issue any thoughts?
It would be really helpful to us if we could do a change like this; do
you think it's likely to be a problem in any way?
Forwarded Message
Subject: adjustment to merge_clusters?
Date: Mon, 30 Nov 2015 07:30:17 +
From: Jon
On 4/12/15 17:14, Tom Hindle wrote:
Hi,
I noticed in windows 10 that when using System Mongolian Baiti Font,
text shaping via harfbuz (seen in firefox + chrome) no longer displayed
the dots bellow the words.
Tested using hg-view.exe using harfbuz 1.1.2
Attached pngs of output from hb-view usin
Hey Behdad,
I'm wondering if we can make merge_clusters a little more conservative?
Here's the scenario:
Assume we start with two independent base glyphs with distinct cluster
numbers:
Then a MultipleSubst lookup expands glyphB to two parts, which both
inherit glyphB's cluster value
On 9/11/15 18:31, Khaled Hosny wrote:
While reading page 13 of John Hudson’s IUC39 presentation [1], I was
wondering if HarfBuzz can handle script, language and direction
properties the same way it handles optional features; i.e. instead of
sending HarfBuzz buffers that has a single script, langu
On 6/11/15 07:45, Behdad Esfahbod wrote:
diff --git a/src/hb-buffer-private.hh b/src/hb-buffer-private.hh
index 721e718..8d9ae7c 100644
--- a/src/hb-buffer-private.hh
+++ b/src/hb-buffer-private.hh
@@ -35,6 +35,16 @@
#include "hb-unicode-private.hh"
+#ifndef HB_BUFFER_MAX_EXPANSION_FACTOR
+#
On 26/10/15 15:37, Nikolay Sivov wrote:
On 26.10.2015 11:30, Simon Cozens wrote:
On 09/10/2015 15:09, Khaled Hosny wrote:
should just use the typographical ascender/descender of the font and
hence not
need glyph bounding boxes in Sile at all.
Yes please, an approach similar to what browsers d
On 9/10/15 14:32, Simon Cozens wrote:
On 09/10/2015 15:09, Khaled Hosny wrote:
On Thu, Oct 08, 2015 at 11:54:09AM -0400, Behdad Esfahbod wrote:
So, from my
point of view, you should NOT use this for line height calculation. You
sho
On 3/9/15 13:01, Behdad Esfahbod wrote:
On Thu, Sep 3, 2015 at 3:36 PM, Jonathan Kew mailto:jfkth...@gmail.com>> wrote:
Hi Behdad,
Just wondering about hb_unicode_eastasian_width, and the underlying
support for it in the unicode_funcs AFAICS this is not currently
u
Hi Behdad,
Just wondering about hb_unicode_eastasian_width, and the underlying
support for it in the unicode_funcs AFAICS this is not currently
used in any way. (Or am I forgetting something important?)
Do you have plans for this at all, or is it truly redundant?
Thx, JK
___
On 8/8/15 15:50, Simon Cozens wrote:
On 08/08/2015 15:25, Behdad Esfahbod wrote:
Ok, that makes sense. And yes, I was ignoring the advance for glyphs and
instead using Freetype to return the glyph width. I think I stole that bit of
code from xetex. :-)
Really?
It may not be totally true. I
(oops, sent the original from the wrong email address so it probably
didn't go through to the mailing list)
On 2/8/15 12:32, Jonathan Kew wrote:
Hey Behdad,
In https://bugzilla.mozilla.org/show_bug.cgi?id=729993, we'd like to
switch Gecko to use HB_BUFFER_CLUSTER_LEVEL_MONOTONE_
On 2/8/15 17:45, Simon Cozens wrote:
Here's an interesting one I came across when implementing Uyghur
hyphenation. The trick in hyphenated Uyghur is to use a ZWJ to ensure
that the last character of hyphenated Arabic morphemes remains in medial
form. However, when I send a Arabic + ZWJ + hyphen s
On 29/5/15 15:16, Koji Ishii wrote:
Sorry if this was asked before, I'm new to this list (and to harfbuzz
too), please accept my apologies if so.
When a variation selector is in the source, such as:
U+0030 U+FE0E
glyph_func receives U+FE0E as variationSelector argument.
What is the expected
On 18/5/15 13:50, Martin Hosken wrote:
Dear All,
A number of people have asked me for a mechanism by which graphite
may be dynamically loaded only when a Graphite font is used. I've
struggled with the notion of this, but I think I understand it now. I
hope that this can help everyone to have wha
On 23/4/15 20:17, Behdad Esfahbod wrote:
On 15-04-23 04:47 AM, Jonathan Kew wrote:
On 28/11/14 21:50, Behdad Esfahbod wrote:
On 14-09-23 04:20 AM, Behdad Esfahbod wrote:
On 14-09-15 05:40 PM, Jonathan Kew wrote:
Hi Behdad,
If the harfbuzz buffer direction is vertical (TTB or BTT), I think
On 28/11/14 21:50, Behdad Esfahbod wrote:
On 14-09-23 04:20 AM, Behdad Esfahbod wrote:
On 14-09-15 05:40 PM, Jonathan Kew wrote:
Hi Behdad,
If the harfbuzz buffer direction is vertical (TTB or BTT), I think we should
refrain from doing Arabic shaping.[1]
We could do this, for example, by
Hi Behdad,
When compiling with MSVC, we have "#define snprintf _snprintf" in
hb-private.hh. However, it seems that MSVC 2015 now provides snprintf
itself, so I think we should use that directly instead, and make the
#define conditional on the value of _MSC_VER.
(See patch 9 in https://bugzil
On 27/1/15 22:06, Behdad Esfahbod wrote:
Ok, CoreText does actually do something. I think it's using heuristics based
on the mark outlines...
Hmm, so it does.
So, we have to choose to match Uniscribe (my current preference), or implement
heuristics (based on glyph extents?).
I don't have
On 26/1/15 22:33, Behdad Esfahbod wrote:
This is by no ways to promote non-Unicode encodings. This is an entry
point that takes Unicode codepoints that happen to all be the first
256 characters and hence fit in 8bit strings. This is useful eg in Chrome
where strings that can
On 26/1/15 22:53, Behdad Esfahbod wrote:
Jonathan,
Trying with sequence of U+308F,3099,308F with NotoSansJP, looks like Uniscribe
doesn't zero the mark advance but we do. The font has bad data for this mark,
but I want to fix the logic discrepancy.
So I'll probably add a new (null-ish) shaper
On 13/1/15 18:29, Jonathan Kew wrote:
On 13/1/15 18:23, Jonathan Kew wrote:
Testcase:
$ echo 4e10,ff41,ff42,ff43,ff44,ff45,4e11 | hb-unicode-encode | hb-view
--font-file msmincho.ttc --face-index 1 --direction ttb
results in poor positioning of the (proportionally-spaced) vertical
variants of
On 13/1/15 18:23, Jonathan Kew wrote:
Testcase:
$ echo 4e10,ff41,ff42,ff43,ff44,ff45,4e11 | hb-unicode-encode | hb-view
--font-file msmincho.ttc --face-index 1 --direction ttb
results in poor positioning of the (proportionally-spaced) vertical
variants of the fullwidth Latin glyphs.
JK
Testcase:
$ echo 4e10,ff41,ff42,ff43,ff44,ff45,4e11 | hb-unicode-encode | hb-view
--font-file msmincho.ttc --face-index 1 --direction ttb
results in poor positioning of the (proportionally-spaced) vertical
variants of the fullwidth Latin glyphs.
JK
_
On 6/11/14 20:10, Khaled Hosny wrote:
On Thu, Nov 06, 2014 at 09:32:26AM -0800, Behdad Esfahbod wrote:
On 14-11-05 11:50 PM, Khaled Hosny wrote:
Tahoma (at least the version shipped in Windows 7) has a kern table,
but no kern feature in its GPOS table, so HarfBuzz will not apply the
kern table
On 10/10/14 02:12, Behdad Esfahbod wrote:
I'm helping Dominik port Chrome's vertical text support to HarfBuzz, and we've
hit a buggy font in Windows, that we need to work around.
"SimSun" on Windows 7, only declares the 'vert' feature under script 'hani'
(fine) language-system "CHN ". No tag ma
Hi Behdad,
If the harfbuzz buffer direction is vertical (TTB or BTT), I think we
should refrain from doing Arabic shaping.[1]
We could do this, for example, by adding an early return such as
if (unlikely (HB_DIRECTION_IS_VERTICAL (buffer->props.direction)))
return;
in setup_masks_arabic(
On 10/9/14 14:58, Vincent Isambart wrote:
Hi there,
I had compiled HarfBuzz with Core Text support thinking it wouldn’t hurt, but I
ended up losing a few hours today because the Core Text backend always loads
the first font of a TTC file, ignoring the font index.
- Is this a known bug?
- Does
On 17/7/14 20:59, Behdad Esfahbod wrote:
New commits:
commit 82f4d9d53f348f41b14b877c1ac77c0372c49caa
Author: Behdad Esfahbod
Date: Thu Jul 17 15:57:37 2014 -0400
[arabic] Add note re disabled 'cswh'
diff --git a/src/hb-ot-shape-complex-arabic.cc
b/src/hb-ot-shape-complex-arabic.cc
in
This looks like a typo?
@@ -311,6 +428,7 @@ struct CmapSubtable
case 10: return TRACE_RETURN (u.format10.sanitize (c));
case 12: return TRACE_RETURN (u.format12.sanitize (c));
case 13: return TRACE_RETURN (u.format13.sanitize (c));
+case 14: return TRACE_RETURN (u.forma
Hi Behdad,
I've opened https://github.com/behdad/harfbuzz/pull/43 with the patches
I'm proposing to fix the legacy Thai case. However, it looks like my
lack of git-fu means that the PR includes a couple of earlier commits as
well; apparently I didn't rebase correctly. Sorry about that!
Anyho
On 9/6/14 22:15, Behdad Esfahbod wrote:
On 14-06-09 10:12 AM, Jonathan Kew wrote:
Hi Behdad,
Our current mark-zeroing code, in zero_mark_widths_by_gdef() and
zero_mark_widths_by_unicode(), modifies only the advance of the glyphs, so
that they no longer take up any space on the line.
Right
On 10/6/14 03:05, Martin Hosken wrote:
Dear Jonathan,
Our current mark-zeroing code, in zero_mark_widths_by_gdef() and
zero_mark_widths_by_unicode(), modifies only the advance of the glyphs,
so that they no longer take up any space on the line.
I'm wondering whether we should also adjust the o
Hi Behdad,
Our current mark-zeroing code, in zero_mark_widths_by_gdef() and
zero_mark_widths_by_unicode(), modifies only the advance of the glyphs,
so that they no longer take up any space on the line.
I'm wondering whether we should also adjust the offset, by subtracting
the advance from it
On 15/5/14 01:19, Martin Hosken wrote:
Dear Behdad,
The previous grammar for medial group was allowing an Asat after
the medial group only if there was a medial Wa or Ha, but not if
there was only a medial Ya. This doesn't make sense to me and
sounds reversed, as both medial Wa and Ha are belo
On 30/4/14 08:30, Preet wrote:
Hi all,
I'm new to i18n and to text rendering so please bear with me if I'm
asking something odd or obvious.
After shaping a run of text with harfbuzz, you can get a codepoint
(font glyph index) and cluster back for each glyph that remains.
I want to use said clu
On 4/3/14 18:47, Behdad Esfahbod wrote:
How about:
_HB_SCRIPT_DUMMY1 = 0x7FFF,
_HB_SCRIPT_DUMMY2
The idea being that DUMMY2 gets value of 0x8000, ensuring that hb_script_t
can represent up to 0x.
In practice I expect that should work, but IIRC a strict reading of the
C+
On 4/3/14 03:52, Behdad Esfahbod wrote:
On 14-03-01 08:38 AM, Werner LEMBERG wrote:
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 rest
On 2/2/14 01:13, Khaled Hosny wrote:
Hi,
Someone reported an issue with the hireq placement under the yodh with
Ezra SIL font[1]. When I checked this, it seemed to be because HarfBuzz
is composing U+05D9 + U+05B4 to U+FB1D and the font has a glyph for
U+FB1D that has a not so good placement for
On 25/1/14 17:36, msk...@ansuz.sooke.bc.ca wrote:
* Conditional on some assessment of the structure of the syllable
(perhaps the existence of a precomposed glyph?) the *jmo features may
be applied - presumably to the output of ccmp, if it was applied.
Yes - remembering that
On 25/1/14 03:14, Dohyun Kim wrote:
Even after removing syllable decomposition table in ccmp and
recompositon table in liga, jieubsida fonts will still have an issue
regarding the case 4, that is multiple jamos to be composed to single
jamo. If current hangul shaper could be modified so that it
ent from a Unicode point of view, even though they "obviously"
(to a human) describe the same fragment of text.
On Mon Jan 20, Jonathan Kew writes:
Is this actually important? Note that Windows behaves similarly, and so
data that has "spelled-out" representations of complex j
On 23/1/14 15:41, Theppitak Karoonboonyanan wrote:
On Thu, Jan 23, 2014 at 9:41 PM, Jonathan Kew wrote:
On 21/1/14 03:56, Theppitak Karoonboonyanan wrote:
I'm trying to typeset Patani Malay text using Thai script as guided by
the Royal Institute, and I have some problems with Ph
On 21/1/14 03:56, Theppitak Karoonboonyanan wrote:
Hi,
I'm trying to typeset Patani Malay text using Thai script as guided by
the Royal Institute, and I have some problems with Phinthu-
modified consonants with below-base vowel combined.
See the sample text captured from the book here:
http://
On 23/1/14 03:39, Dohyun Kim wrote:
I've just found that jieubsida fonts [1] from Tsukurimashou Font
Project [2] do not work well with current hangul shaper.
~$ hb-unicode-encode AC00 | hb-shape --script=hang JieubsidaBatang.otf
[uni1100=0+0|uni1161=0+833]
Expected output is:
~$ hb-unicode-enc
On 22/1/14 12:53, Behdad Esfahbod wrote:
Thanks Jonathan. I've merged these.
A few points:
/* Same order as the feature array below */
enum {
NONE,
LJMO,
VJMO,
TJMO,
FIRST_HANGUL_FEATURE = LJMO,
HANGUL_FEATURE_COUNT = TJMO + 1
};
Do you really need the NONE? I don't see w
On 20/1/14 15:26, Dohyun Kim wrote:
I just have tested this kind of input string and the result is a
little disappointing:
Input string does not rendered well. The
output of current (patched) harfbuzz with UnBatang font is
[uni1121=0+1024|uniD0C0=2+1024], the expected output being
[uniA972.xxx
On 20/1/14 16:02, Dohyun Kim wrote:
And I found a minor bug:
--- hb-ot-shape-complex-hangul.cc.orig2014-01-21 01:00:25.0 +0900
+++ hb-ot-shape-complex-hangul.cc2014-01-21 00:57:44.0 +0900
@@ -214,7 +214,7 @@
if (font->has_glyph (0x25cc))
{
hb_codepoint
On 20/1/14 02:21, Roozbeh Pournader wrote:
Jonathan,
I was wondering if the new patches would have all the canonically
equivalent characters sequences rendered the same way. Microsoft people
have said publicly that their Hangul shaper intentionally doesn't do that.
The intention is that canon
orresponding LVT syllable), but we handle by decomposing to T> and applying jamo features.
JK
commit 311490e6109c997887bc8012e41473b870b67ceb
Author: Jonathan Kew
Date: Sun Jan 19 23:31:16 2014 +
[ot-hangul] Apply the appropriate *jmo features to decomposed syllables,
including Old Hang
We've talked about this at some point in the past, and IIRC Behdad was
reluctant, but I think we should just fix harfbuzz to respect the OMPL,
exactly as spec'd. Even though it's an ugly solution.
JK
On 18/1/14 11:56, Khaled Hosny wrote:
Hi Behdad,
According to the spec[1] character mirrorin
rally be trying as many non-matching lookups on every glyph;
we'll only apply the lookups for (at most) one of the *jmo features,
instead of all of them.
WDYT?
On 6/1/14 14:44, Jonathan Kew wrote:
The Hangul shaper should NOT apply the *jmo features to glyphs that are
not part of
The Hangul shaper should NOT apply the *jmo features to glyphs that are
not part of a properly-structured Korean syllable.
Some examples of current behavior:
[GOOD: complete LVT sequence, proper features applied]
hb-unicode-encode 1101,1161,11f0 | hb-shape UnBatang_0613.ttf
[uni1101.ljmo01=0+10
On 3/1/14 11:57, Khaled Hosny wrote:
On Fri, Jan 03, 2014 at 10:07:50AM +, Jonathan Kew wrote:
On 3/1/14 06:12, James Clark wrote:
On Mon, Dec 30, 2013 at 7:26 PM, Jonathan Kew mailto:jfkth...@googlemail.com>> wrote:
There's overlap here with the process of font-matchin
On 3/1/14 11:28, James Clark wrote:
On Fri, Jan 3, 2014 at 5:07 PM, Jonathan Kew mailto:jfkth...@googlemail.com>> wrote:
In order to do fallback,
you need to do character to glyph mapping.
Not necessarily. You need to know the character repertoire supported
On 3/1/14 06:12, James Clark wrote:
On Mon, Dec 30, 2013 at 7:26 PM, Jonathan Kew mailto:jfkth...@googlemail.com>> wrote:
There's overlap here with the process of font-matching (choosing the
font(s) to be used for a given text sequence), which is clearly out
of scope f
On 2/1/14 10:17, Werner LEMBERG wrote:
[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_
On 31/12/13 09:53, Behdad Esfahbod wrote:
I've now pushed a Hangul shaper out to HarfBuzz master. Here's the comments
explaining what it tries to do:
> ...
Thanks for working on this. Looks good so far (though I haven't tested
in any real depth).
The one thing I don't see here is any suppor
Some comments on a few of the items from your list:
API ITEM: unsigned int vs uintptr_t / size_t:
Use uintptr_t / size_t instead of unsigned int throughout the API? Which one?
This has ABI implications on 64-bit architectures. My current thinking is
that we should do this.
Agree (althoug
On 27/12/13 16:21, Ed Trager wrote:
Hi, Martin, Richard, and Danh Hong,
With regard to forcing the re-ordering of the
UCD-enforced-but-totally-broken normalisation of TAI THAM TONE MARK plus
U+1A60, does the following approach in the OpenType feature file make
sense as the quickest and cleanest
On 22/12/13 21:21, Behdad Esfahbod wrote:
+ if (!(frac_mask | numr_mask | dnom_mask))
+ return;
Maybe it would be better to require *both* numr and dnom to be present
if they're to be used. Something more like
if (!frac_mask && (!numr_mask && !dnom_mask))
return;
perhap
On 16/12/13 15:21, Bob Hallissy wrote:
Looking briefly at the GSUB lookups, I don't see the language-specific
lookups I'd expect. In the 1.x font, it looks like we handled this
within the 'calt' feature (which is a little odd - I'd have expected
it in 'locl' - but perhaps we had a good reason fo
On 16/12/13 15:44, Martin Hosken wrote:
> Dear Bob,
>
>> On this subject: I would have expected language-specific forms to
>> work with Graphite rendering since the language table therein
>> appears to work (at least it does with WorldPad -- admittedly using
>> the old Graphite engine):
>
> There
#x27;s also been
observed in HarfBuzz separately from Firefox.
JK
Original Message
Subject: Re: [HarfBuzz] Questions regarding hb_language_t
Date: Sun, 15 Dec 2013 19:23:07 -0500
From: Behdad Esfahbod
To: Ariel Malka , rooz...@google.com
CC: Khaled Hosny ,
harfbuzz@lists.freed
s
struct hb_feature_t {
hb_tag_t tag;
unsigned int value;
}
// only used by shape API
struct hb_feature_range_t {
hb_feature_t feature;
unsigned int start;
unsigned int end;
}
But maybe it's too late to go that way.)
On 13-10-30 03:02 PM, Jonathan Kew wrote:
On 29/10/13 23:03, Behdad Esfahbod wrote:
On 13-10-29 10:10 PM, Jonathan Kew wrote:
So I'd suggest it's worth doing something like this - unless of course you
want to go the whole way and implement "smart" plan caching with user
features, but IMO that sounds like it might
uthor: Jonathan Kew
Date: Tue Oct 29 19:16:43 2013 +
remove unused is_inplace methods and associated struct
diff --git a/src/hb-ot-layout-gpos-table.hh b/src/hb-ot-layout-gpos-table.hh
index 103676b..5e4326e 100644
--- a/src/hb-ot-layout-gpos-table.hh
+++ b/src/hb-ot-layout-gpos-table.hh
@@ -14
test tools would be redundant.)
On Oct 29, 2013 10:10 PM, "Jonathan Kew" mailto:jfkth...@googlemail.com>> wrote:
Hey Behdad,
I figured out why the dashboard figures make it look as though we're
surprisingly slow when running the XP fonts with simple scripts
#x27;d suggest it's worth doing something like this - unless of course
you want to go the whole way and implement "smart" plan caching with
user features, but IMO that sounds like it might be more effort than
it's worth.
JK
commit fd387acc173e128101f2e556e44927cebd18a010
Auth
e general positioning rules.
Maybe you should read up about the OpenType layout process...
http://www.microsoft.com/typography/SpecificationsOverview.mspx
On Tue, 29 Oct 2013 10:40:59 +, Jonathan Kew wrote:
On 29/10/13 10:19, eduardo wrote:
Hi,
Why does hb return a list of advances when, g
On 29/10/13 10:19, eduardo wrote:
Hi,
Why does hb return a list of advances when, given a glyph, it can easily
be extracted from the font? Are the glyph advances context dependant? If
so, what is a good language/script to see the difference?
Yes, of course they're context-dependent. The simpl
On 28/10/13 14:47, Behdad Esfahbod wrote:
On 13-10-28 02:47 PM, Jonathan Kew wrote:
See what you think. An alternative implementation might be to initialize the
is_inplace flag during hb_ot_layout_lookup_accelerator_t::init() (then no need
for the _initialized flag, hence taking an if() out of
Hey Behdad,
Turns out that for fonts such as Noto Devanagari and Gujarati, we're
spending an inordinate amount of time under lookup.is_inplace
(&inplace_c) in apply_string().
We can get a big win for these fonts if we cache the is_inplace result
in the lookup-accelerator, instead of recursin
It's a relatively small thing, but we can get a slight win for the case
where kerning has been disabled if we add an early return to
_hb_ot_shape_fallback_kern().
Looks to me like we can also reduce the use of buffer->... there when
kerning is being applied, which might help a bit (depending h
I've added performance numbers to the shaping comparison suite results
at http://ec2-54-226-13-158.compute-1.amazonaws.com/index.html. The
"timings" column lists the total number of seconds spent within
hb_shape() for the "native" HarfBuzz OT and Uniscribe backends, and the
percentage delta for
On 23/10/13 20:02, Shriramana Sharma wrote:
Hello. My local HB Git clone is at
ac8cd511911c7dca6222d14fa758bff75d601567 which git reports to be
up-to-date.
For some reason HB seems to have gone haywire in doing Indic
reordering. I tested Devanagari, Tamil and Malayalam.
Seems to work OK here.
On 22/10/13 00:20, Behdad Esfahbod wrote:
On 13-10-20 01:44 PM, Shriramana Sharma wrote:
Hello. I'm running Clang 3.2 on Kubuntu Saucy.
Generally these warnings seem to be Ok.
Not entirely. The warning about OT_CM2 here:
hb-ot-shape-complex-indic.cc:166:27: warning: shift count >= width of
Turns out that zeroing marks by GDEF in Tibetan (commit
d5bd0590ae2fbc7b0dee86385a565aef00ffb835) has significantly regressed
our numbers for the Windows himalaya.ttf font. :(
The main problem seems to be the handling of
0F3C;TIBETAN MARK ANG KHANG GYON;Ps;0;ON;Y;TIBETAN LEFT BRACE
1 - 100 of 260 matches
Mail list logo
