Search
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:03:12
jackdaniel
you may cheat and implement the correct behavior in cl
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:06:54
loke
It will slow down text rendering though, so perhaps it should be optional?
14:07:48
jackdaniel
I don't understand. the only scenario where you hit the slower path is when you explicitly say :rtl
14:08:38
loke
You can have a plain ltr string that contains some arabic text inside it.
14:09:05
loke
The bidi algorithm identifiex these sections (called "runs") and splits the string on them.
14:09:37
jackdaniel
it is more text preparation than rendering, isn't it?
14:09:44
jackdaniel
that should be fast compared to graphic operations
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
14:12:11
jackdaniel
benchmarking bidi and fixing hot paths is an option if it is slow
14:18:55
loke
are you ok with my pull req by the way?
14:21:35
jackdaniel
I'm working on something else right now