Created attachment 195526 [details] Screenshot of bug manifesting To reproduce: 1. Create a new document 2. In, Format > Page... set "Text Direction" to "Left-to-Right (Vertical)" (that actually sets the writing mode, not the text direction in the sense we're used to; see bug 162200 about the terminology) 3. Type some RTL and LTR text, e.g. "Hello لوك goodbye" (note the two Arabic letters with ascenders at the beginning and near the end of the word) 4. Scroll the page up and down, to account of the effect of any painting glitches Expected results: The three words share the same (vertical) baseline and are thus aligned Actual results: The Arabic word is aligned almost a full line to the left of the English words. You don't see most of it, and only the top edges of the ascenders are visible (see screenshot) Note: This is possibly one of the issues which underlie bug 50202 - although there, the offset is in the opposite direction somehow. Screenshot created with build: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: dc9486f2443fa52588b625c0a2a288bff56a7a45 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US Calc: CL threaded
Well, it seems this is _exactly_ the remaining issue underlying 50502, as if we change the paragraph direction to RTL, the offsetting works the other way around: RTL text has the correct offset, LTR text is offset to the left. Test document to follow.
Created attachment 195528 [details] Document with the bug manifesting
This is the outstanding portion of a bug originally filed in 2012. Marking as new.
(In reply to Jonathan Clark from comment #3) I should also mention that there are all sort of hard-to-reproduce glitches when editing RTL-language text in vertical-lr writing mode: * Sometimes you see the whole offset RTL text, sometimes you don't * ... and it can change when scrolling or typing another letter * Sometimes I see the cursor moved to the opposite end of the page, and off the page and I might even be missing some things. I realize that might be a separate bug, or multiple bugs; or it might just go away when this is fixed, but still worth mentioning here - there may be different places in the code which make conflicting assumptions about how and where things are laid out (including cursor placement and repainting).
Please also consider that vertical writing with fonts that support vertical writing will stamp rotated glyphs, and as described in OTF 'VORG' table will specify the baseline to use. Fonts without alternate vertical handling will set baseline to follow their metrics in the writing orientations of bug 162200.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/89ff0796a812179a56d6802a5397c4f51e0c2e09 tdf#162205 sw: Fix incorrect baseline adjust for vertical bidi portions It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to V Stuart Foote from comment #5) > Please also consider that vertical writing with fonts that support vertical > writing will stamp rotated glyphs, and as described in OTF 'VORG' table will > specify the baseline to use. > > Fonts without alternate vertical handling will set baseline to follow their > metrics in the writing orientations of bug 162200. Thanks for pointing this out. There was a relatively straightforward logic error causing Writer to behave differently when drawing bidi portions, so I focused on resolving the inconsistency. I haven't studied whether we handle these types of fonts correctly in general, but at least the behavior should be the same whether the text is contained in a text portion or a bidi portion.
There might be some other bugs related to vertical layout of RTL text in tables, which may be affected.
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/43f997888a4c6578f23c39cdef0f8dc356e74454 tdf#162205 sw: Fix incorrect baseline adjust for vertical bidi portions It will be available in 24.8.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.