Description: Hello. The format that is applied to the text and characters inside a graphical terminal emulator –Bash for instance– has these properties: - left-sided text alignment - hyphenation disabled - mono-spaced font - each row of a one-lined text whose total characters' length is several times wider than a terminal row's width, is entirely filled by a part of the text which, once it reaches a end of row, breaks there. See attachment. Steps to Reproduce: 1. Choose a style with these properties: - left-sided text alignment - hyphenation disabled - mono-spaced font 2. Insert into document various one-lined texts whose total characters' lengths are several times wider than Writer row's width. Actual Results: When it comes to Writer, it seems to me that it lacks an option to control that latter property. Also noticeable in the two illustrations in the snapshot of the document, is the inconsistency of the rules that govern the breaks. See attachment. Expected Results: Introduction of the above depicted property. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.5.1; Build ID: 40(Build:1); CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI: en-US; Calc: threaded
Created attachment 185228 [details] Comparisons of text's breaks | Writer document and, above it, graphical terminal emulator
So the text break should not occur at the first logical break--the space--as normal now, rather against some sense of a line buffer. Ignoring the word boundary (i.e. white space) that is the logical break when the following text run is overlenghth. Buffer would need to be calculated for font size against what can be contained within the page, column or frame margins. And then it would break as the line buffer fills. Or for readability would it break for specific characters (like a hyphen break does currently). OK, but I guess the real thing is what is the use case for the work it would require? Seems out of norm from ODF document model. But I guess would be utility for using Draw, Impress or Writer to author training and demonstration materials for working with a terminal? But seems very much a corner case and maybe outside project scope?
Wonder about the use case too. And as we aim for compatibility with competitors it should be consistent with MSO. Do you have a good real-life example, Rick?
That seems to be a case rather parented to Matryoshka dolls. As your the-real-thing is itself within an other the-real-thing, thus a bigger one. Bigger doll | Those who once upon a time planned to create Writer must have asked themselves something as pertinent as "What would be the use-case for the work it would require?". Have you at the time answered by asking yourselves "What would make it (Writer) to be what we (developers) would like it to be?". Presumed answer: "a versatile word processor". And indeed versatile, it has to be, so that the document is what its author wants it to be. Yet this could at best be a dynamic goal, since you (developers) restlessly are attempting to achieve it by making Writer a better word processor. Smaller doll | By the very act of creating a new ODT-typed document, regardless being both a developer and user or non-developer and user of Writer, we dully expect to master the final presentation of the content inserted into that document. It would not be singular use-cases in nowadays' world to be in situation of having to create an ODT document aiming to contain command-line expressions in the purpose to serve the creation of a source either of documentation, user-manual, technical guide, teaching material or any illustration of command-line expressions for pedagogic scenario, be it aimed to be used as digital material or paper book. In such a context a presentation (no matter it is served by Writer or a competitor) of command-line expressions that would not rigorously observe the rules being prevailing within the terminal emulator would make no sense.
(In reply to ricky.tigg from comment #4) Again, "Do you have a good real-life example"? Specifically how and in which module would such non-standard paragraph formatting be helpful? For limited layouts, the effects can already be achieved now with text boxes in all LibreOffice modules. Is that not sufficient? How many of such "emulated" terminal lines would be needed in a document or presentation? Enough to require new line break paragraph logic?
(In reply to V Stuart Foote from comment #5) > Again, "Do you have a good real-life example"? No response, resolving ID.