Design/Meetings/2025-10-08
Appearance
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Link
https://listarchives.libreoffice.org/global/design/2025/msg00094.html
Minutes
Present: Sahil, Jonathan, Eyal, Ted, Dhantel, John, Heiko
Comments: Regina, Stuart
Tickets/Topics
* show outlines around selected objects like shapes, charts etc
+ https://bugs.documentfoundation.org/show_bug.cgi?id=168562
+ View > Boundaries should work for all objects incl. images, charts,
shapes and not just for tables, frames and math-objects (Regina, Stuart)
+ marching ants are an indicator for copied objects (Heiko)
+ if the object has a border itself the selection might not
be obvious (Heiko)
+ marching-ants-like frame just looks nicer; but not proposing animation,
only a static frame (Sahil)
+ MSO connects the eight-dots with a straight frame (Heiko), OnlyOffice
does too (Eyal)
+ no strong argument against the change, neither for it other than
design (Eyal, Ted)
+ should be active depending on the boundaries option (Heiko)
=> do it
* The default table pseudo-style should be master-slide-specific rather
than template-global
+ https://bugs.documentfoundation.org/show_bug.cgi?id=168592
+ agree, styles should behave like styles (Heiko)
+ We currently have a default choice of one of the table pseudo-styles,
which is the same for tables inserted on slides regardless of their
master (Eyal)
+ The request is to keep for each master, a choice among the available
table pseudo-styles; the request is orthogonal to whether or not
the pseudo-styles are stored with the documents or not (Eyal)
+ For the long-term, would like a deep revamp of the table pseudo-style
mechanism, and to have proper table styles (as per bug 151264), while
this is a minor adjustment for the current state of affairs, hopefully
requiring little effort (Eyal)
+ feels short-sighted to me; misses the point of storing/sharing TS,
handling TS like any other style, and would be incompatible (Heiko)
=> comment
* Extrinsic vs intrinsic paragraph direction (Eyal)
+ https://listarchives.libreoffice.org/global/design/2025/msg00088.html
+ DF RTL followed by "Clear DF" retains RTLness, aligns left
+ https://bugs.documentfoundation.org/show_bug.cgi?id=168537
+ "Clear Direct Formatting" clears RTL directionality
+ https://bugs.documentfoundation.org/show_bug.cgi?id=40496
+ Switching paragraph styles removes explicit text direction choice
+ https://bugs.documentfoundation.org/show_bug.cgi?id=58070
+ Auto-detect paragraph directions when they were not set explicitly
+ https://bugs.documentfoundation.org/show_bug.cgi?id=162120
+ Philosophically, the writing direction is _sometimes_ a property of
the text itself, or implicit in it; but - not in every scenario and not
for every written language. (Eyal)
+ in CJK, text direction is a formatting choice, but in RTL,
text direction is a semantic property of the paragraph (Jonathan)
+ There are two "extreme" or pure approaches to this matter: Direction
only from the text via auto-detection, with no override; or direction
only via formatting/styling, ignoring the content completely. The
second extreme approach is essentially the current approach of
LibreOffice and of ODF. (Eyal)
+ Users have at least two interests not satisfied by our current
approach: (Eyal)
+ The desire to avoid manually setting directions for text being pasted
or imported from text(-ish) files.txt
+ The desire to avoid replicating styles, with the "same" styles needed
both for RTL and LTR text
+ auto-detection as defined by Unicode vs. formatting as LibreOffice does
+ missing a use case for either of options (Heiko)
+ A related issue is the treatment of language as a property of the
character style, which is currently what LibreOffice does, and that is
wrong (Jonathan, Eyal)
+ Three suggestions for addressing user interests in auto-detection:
+ More far-reaching:
Add another (horizontal) direction option for paragraphs: 'automatic',
in addition to 'inherit', 'ltr', 'rtl'. It will be used by default
for imported text files and perhaps for multi-paragrph stretches of
important text. This will require a minor ODF change (Eyal, Jonathan)
+ ... with a single detection logic, as mandated by Unicode (Jonathan)
+ ... with several, or flexible, detection logics, as the Unicode
detection logic is too simplistic (Eyal)
+ Less far-reaching:
Add a command for applying auto-detection logic to paragraphs, and apply
'rtl' or 'ltr' to them (as DF). auto-detection not "remembered" in the
saved document (Heiko).
+ Changing the ODF standard would need consensus (Heiko)
+ Can always ask the ODF TC what they think (Jonathan)
+ re: vertical (CJK, Mongolian script), I don't think any changes
are needed (Jonathan)
+ we have detection algorithms built-in for the language (Heiko)
=> no objection to the proposal