Whats holding ~100% D GUI back?

[H. S. Teoh]

On Fri, Nov 29, 2019 at 11:19:58PM +1300, rikki cattermole via Digitalmars-d wrote:
> On 29/11/2019 10:55 PM, Basile B. wrote:
> > 
> > Back to the original topic. What people don't realize is that a 100%
> > D GUI would be a more complex project than the D compiler itself.
> > Just the text features is a huge thing in itself: unicode, BDI.
> 
> Assuming you mean BIDI yes. Text layouting is a real pain. Mostly
> because it needs an expert in Unicode to do right. But its all pretty
> well defined with tests described. So it shouldn't be considered out
> of scope. Font rasterization on the other hand... ugh

Text layout is non-trivial even with the Unicode specs, because the
Unicode specs leaves a lot of things to implementation, mostly because
it's out-of-scope (like the actual length of a piece of text in pixels,
because that depends on rasterization, kerning, and font-dependent
complexities -- some scripts like Arabic require what's essentially
running a DSL in order to get the variant glyphs right -- not to mention
optional behaviours that the Unicode spec explicitly says are up to user
preferences). You can't really do layout as something apart from
rasterization, because things like where/how to wrap a line of text will
change depending on how the glyphs are rasterized.

Also, layout in my mind also involves things like algorithms that avoid
running streams of whitespaces in paragraphs, i.e., LaTeX-style O(n^3)
line-breaking algorithms. This is not specified by the Unicode
line-breaking algorithm, BTW, which is a misnomer: it doesn't break
lines, it only finds line-breaking *opportunities*, and leaves it up to
the application to decide where to actually break lines. Part of the
reason is because Unicode doesn't deal with font details. It's up to the
text rendition code to handle that properly.


T

-- 
It only takes one twig to burn down a forest.