GNOME Bugzilla – Bug 323174
Add high-level layout negotiation for complex vertical layout
Last modified: 2007-05-24 20:04:08 UTC
Splitting bug 99523. Phase 3, in which we rule the world. Real fun begins when we consider longer term implications of having proper, working vertical layout (think vertical GTK+). This is kind of blue-sky, but needed if we want to make it really useful. Consider this, fairly simple use cases: 1) Group of Chinese scholars discussing some political matters on IRC. Being educated scholars, they use original Arabic names when talking about near-East politics, and also touch on some subjects involving CIA and FBI, so have pasted those abbreviations several times. 2) Group of Japanese hackers in the middle of hackfest. They discuss their architecture a lot, so much is being said, also they throw code around a lot, pasting relevant lines of C into IRC directly In case 1), you clearly want both Arabic and Latin names to be inlined in primarily vertical text, also for Latin abbreviations you'd prefer full-width forms to be used. In case 2), you want primary text to still run vertically, however for large chunks of text, you want them to be laid out horizontally (you really don't want to read 15 lines of C lying on side) This requires more consideration than tn22 can give us (which cowardly dodges the question by stating it's higher level's business). That is, it is what tn22 calls box layout. What would be needed here is, first, smart logic which would automagically decide on whether to inline or do stuff out of line. Second, as we can't really know everything, we want some kind of protocol for "layout negotiation" with apps, which will hopefully know more about the text and could give us some hints on the right decision. This is gonna be complicated, but probably the only way to take it to the next step, towards real vertical UI (figuring right API on GTK+ level is another fun part).
First, I think this is unnecessary. Automagic is dangerous magic, and the limits that control what you're trying to do here are going to be very subjective. Also, I'm not familiar with the scope of Pango, but if you don't already have a box layout system, this is not a good enough reason to add it. Second, I think your use cases are contrived. The Japanese are comfortable with horizontal layout as well as vertical, and you'll find that in contexts where a lot of horizontal text is expected, as in science, math, and engineering, the Japanese tend to use horizontal layout anyway. In cases where the layout is vertical, English paragraphs will be vertical, too. Yes, whole paragraphs. See http://fantasai.inkedblade.net/style/discuss/directions/scans/genji3 In magazines you'll see mixed horizontal and vertical layout within a single page, but those layouts were all done by a graphic designer to carefully fit *just* the right amount of text while aesthetically balancing the visual design. In a computer system, you're going to code heuristics for this, and while that might make some cases "just work" it will also make other cases "just break". I would focus instead on improving the details of Pango's vertical text support, and making sure it's well-tested and well-documented. Mixed-layout text isn't for plain text display anyway, and it would be better if Pango were a high-quality renderer for embedding in layout engines like word processors and web browsers than if it had a few quirky features to let plaintext applications pretend they can do box layout.
(In reply to comment #1) > First, I think this is unnecessary. Automagic is dangerous magic, and the > limits that control what you're trying to do here are going to be very > subjective. Also, I'm not familiar with the scope of Pango, but if you don't > already have a box layout system, this is not a good enough reason to add it. Generally agreed. I think this bug only makes sense on Gtk+, not Pango. And even for Gtk+, I share your opinion that this better be left to the user.
Ok, closing as I don't see anything coming out of this bug.