freenode/#clim - IRC Chatlog
Search
13:13:36
loke
I'm not sure how to fix that. If you have a fork of a project, and you make one commit to it (which is later reverted so that the master is identical to the forked project aagin) then whenevr you branch off it and create a pull request, Github will list every single change since that original change
13:24:08
loke
jackdaniel: I've created a new branch on the main McCLIM repository and created a pull request from there instead.
13:32:33
jackdaniel
I usually perform rebase against target branch to reduce number of commits and then squash where appropriate
13:34:34
jackdaniel
if you have now access to all that information (most notably dx), then you may want to have a fast method for text-size
13:37:36
loke
jackdaniel: in freetype (or more accurately, Harfbuzz) a glyph location is not constant.
13:38:28
loke
The method string-to-clyph-list (or whatever it was called?) needs another argument: The text direction
13:42:15
loke
But it raises a question: In truetype, if you want to get the glyph list for a givel RTL string, are the resulting glyphs in rtl or ltr order?
13:46:23
loke
Basically, when you call the font shaping engine, it returns a list of glyphs in left-to-right order, regardless of the ordering of the string. I found mailing list post on the harfbuzz mailing list that calls this the "opentype model"
13:46:40
jackdaniel
also you depend on the underlying mechanism "getting" rtl for you. one could imagine, that font-string-glyph-codes caller takes care of butchering string
13:47:02
loke
So in the freetype renderer, FONT-STRING-GLYPH-CODES returns a list of glyphs in visual order (left-to-right).
13:49:32
loke
jackdaniel: yes, but there is no 1-to-1 correlation between codepoints in the text and glyphs
13:50:41
loke
Inside the string there can also be rtl-ltr override characters that switches the direction.
13:51:05
loke
Harfbuzz deals with all that, and converts it to a sequence of glyphs + thir offsets where they should be drawn.
13:52:34
loke
However, the renderer needs to know the outer ordering (bascially the ordering that it should use at the start), and that's passed in as as argument to the shape engine.
13:53:12
jackdaniel
I wonder what your point is: are you trying to convince me to something; or maybe I'm playing a rubber duck here?
13:53:39
loke
jackdaniel: I'm trying to convince you that the function font-string-to-glyph-codes needs an (optonal?) argument specifying the tinitial text direction
13:54:53
jackdaniel
I'm not opposed to that chang, make a pull request which changes the function definition and all methods to match that
14:00:09
loke
jackdaniel: I do note that this function is mainly used in the fallback code when there is no renderer-specific implementation.
14:00:39
loke
So in that sense, it doesn't matter as much that the function is somewhat underspecified for complex strings.
14:02:15
loke
I will propose an extra keyword argument that specifies direction. Should it error on the treutype renderer, or ignore it?
14:02:41
jackdaniel
like font-text-extents default method ignores the argument this one should do the same
14:04:18
loke
Basic right-to-left rendering should be doable. That should be useful for Hebrew at least which doesn't need a complex shaper.
14:06:23
loke
We have the bidi.lisp implementation already, so it should be rather simple to implement support for it.
14:07:48
jackdaniel
I don't understand. the only scenario where you hit the slower path is when you explicitly say :rtl
14:09:05
loke
The bidi algorithm identifiex these sections (called "runs") and splits the string on them.
14:10:37
loke
I've never actually benchmarked it. But bidi.lisp currently works with lists rather than vectors, so it just "feels" slow to me.
14:11:39
jackdaniel
you may make it optional first and when we see how it performs we may decide something