@enkiv2 @zens@merveilles.town @alcinnz @mathew @BillSeitz Maybe DSSSL then? There's no reason this stuff has to be slow or write-only!

@radehi

my extremely unpopular opinion: start with plain text, and then have a separate set of formatting rules that operates on byte offset pairs.

@zens @alcinnz @mathew @BillSeitz

@enkiv2 @zens@merveilles.town @alcinnz @mathew @BillSeitz Sure, like Xanadu links. Do you have a prototype of your offset-markup layout approach running?

@radehi
Yeah.

I don't have the one I did for Xanadu up, since it's not open sourced yet, but here's something that translates between a span-based format and tkinter's mark-based format: https://github.com/enkiv2/misc/tree/master/mtv

(It's more complicated than it needs to be, because tkinter has a coordinate system for text positions that's fiddly and underspecified.)

@radehi

With the one we did for xanadu, there's a little more flexibility because we were rolling our own layout & formatting code, so in theory, the ODL could be used to place individual chunks of text in arbitrary relation to other chunks of text.

(Actually, text layout was sitting on top of ZZOGL, which itself is extremely flexible -- intentionally supporting everything that you could do with pasteup and more, since it's in three dimensions. But by default, we have 'page'-like structures called slabs, oriented in parallel, with translucent ribbons between them, and text is put on the front surface of the slabs.)

The 3d support was straightforward but getting fast hardware-accelerated text rendering for large quantities of text that was portable across a large variety of cards was really complicated, to the point where we had to drop the project. 90% of the logic could be applied to a single plane with simple perspective + parallax and just dropped into SDL, but we were too fried at the time to implement that.

@enkiv2 @radehi @zens @mathew @BillSeitz Very much against what I'm seeking to accomplish!

@alcinnz
yup, hence unpopular