I miss the function View-> Non-printing Characters in Draw like Writer has it. It would be helpful to be able to view non-printing characters in text boxes.
Let's hear what the UX team has to say on this.
What is the use case? I mean it sounds like a lot of work for no good reason. By the way, it's not only Draw that doesn't show line breaks in text boxes, its also true for Writer.
Whether in the Draw/Impress module, or Writer, or Calc-- a Text Box is a Draw object held within its anchored Draw frame--it is rendered as BMP meta onto the document canvas, layered as specified. While the Text content of the Text Box (or Text annotation onto a Draw Shape) is technically a Paragraph--it does not have the same methods available to Paragraph objects on the Writer canvas or within Document Frames on the Writer canvas. Display of non-printing characters (returns, line breaks, spaces, tabs, non-breaking spaces/tabs, etc.) within a Text Box, or the Text annotation of a Draw Shape, are simply missing method(s) for the class(s). It could be implemented, but as Heiko notes--what is the use case? As is you have immediate feed back on any formatting changes applied to the Text of a Draw Text Box, or Text annotation of a Draw Shape. What more is needed that would aid composition?
I stumbled upon that issue when editing a text box in Draw where there was a spacing about 3cm between two words and it wasn't clear to see of how many spaces and tabs it was composed of. I would think it would be fine to only show the non-printing characters of one text box when editing the text in it.
If Draw wants to have better DTP features, it should likely implement this, as it is available in scribus.
If we start with non-printable characters I wonder what feature we will not accept. How about numbering? (IIRC there are feature requests) Do we want highlighting (background and foreground color per character)? Can a paragraph/character style applied to the text box? Do we allow embedding of objects? Should the text box have an area fill style? etc.
(In reply to Heiko Tietze from comment #6) > If we start with non-printable characters I wonder what feature we will not > accept. Well as this feature should already be in writer, i'd give an exception for this one, but whether a feature will or not be acceptable will always come down to how feasible it is to achieve from a coding perspective and whether ODF supports the feature. @thorsten, @armin, @maxim: Any thoughts on how feasible this is? > How about numbering? (IIRC there are feature requests) No idea about this. > Do we want highlighting (background and foreground color per character)? We already have this. > Can a paragraph/character style applied to the text box? We do have graphic styles in impress/draw, which can be considered similar to paragraph styles. For writer, i think that paragraph and character styles should be available in textboxes, just like they are available in frames and sections, as well as being good for MSO compatibility. > Do we allow embedding of objects? We do allow object embedding (e.g. chart, formula) or am i missing something? > Should the text box have an area fill style? Graphic styles include area fill.
(In reply to Yousuf Philips (jay) from comment #7) > We do allow object embedding (e.g. chart, formula) or am i missing something? Talking about text boxes. And there is no filling possible, e.g. a background image. And a text box must remain a text box on Impress/Draw as well as Writer, so a paragraph style must not be replaced by something else. (I wouldn't apply styles to text in a box, neither embed objects. But everything else would be nice.)
I personally use non-printing characters as blanks and CR in my code editor, and it would be possible to do this for EditEngine, too, but - the question is - where is the win? Of course one glance on the EditView compared with klicking in it and using the cursor keys to travel over the parts in question, but really quite some work to be done to do this and to guarantee that this is only shown in the EditViews.
Draw == Impress *** This bug has been marked as a duplicate of bug 95066 ***
As this bug has UX discussion and dev input and isnt just limited to Impress/Draw, bug 95066 should be closed as a duplicate of this.
*** Bug 95066 has been marked as a duplicate of this bug. ***
*** Bug 99390 has been marked as a duplicate of this bug. ***
Case for formatting a Draw Text box object placed in Writer seems to be in see also bug 102248, should there be rework to put them all on the same code? Should this issue address all instances of the Draw Text box object?
(In reply to Armin Le Grand (CIB) from comment #9) > I personally use non-printing characters as blanks and CR in my code editor, > and it would be possible to do this for EditEngine, too, but - the question > is - where is the win? I would assume that it would be a win in writer for a setting that affects all text of the document to also affect text in shapes and textboxes, else it feels like broken functionality. > Of course one glance on the EditView compared with > klicking in it and using the cursor keys to travel over the parts in > question, but really quite some work to be done to do this and to guarantee > that this is only shown in the EditViews. Well using the cursor key wont tell you if a space is a regular space or a non-breaking space, or with soft hyphens appearing as if something is between the two characters, but a user unfamiliar with it wouldnt know what it was and possibly would delete it.
@Comment 14: The EditEngine is used in Draw/I)mpress/Calc TextFrames, some Writer TexdtFrames, and in all DrawShapes using Text. Also in Calc when a cell is active, in Tables (the Draw/Impress ones, not sure about Calc ones, probably not for Writer Tables), also in OutlineMode in Draw/Impress. All these usages would/may support this eventually if added to EditEngine. @Comment 15: Good args - I would see it as a win, too. Technically (and UI) there are open points - with CR visualization at the end of line, 'text' would be outside the TextFrame, at least overlapping. These vis-oly-chars should not be used in layouting (no extra width with visible CR)
*** Bug 102248 has been marked as a duplicate of this bug. ***
(In reply to Armin Le Grand (CIB) from comment #16) > @Comment 14: > The EditEngine is used in Draw/I)mpress/Calc TextFrames, some Writer > TexdtFrames, and in all DrawShapes using Text. Also in Calc when a cell is > active, in Tables (the Draw/Impress ones, not sure about Calc ones, probably > not for Writer Tables), also in OutlineMode in Draw/Impress. All these > usages would/may support this eventually if added to EditEngine. OK, have set 102248 as duplicate here and adjusted summary.
*** Bug 107313 has been marked as a duplicate of this bug. ***
*** Bug 123443 has been marked as a duplicate of this bug. ***
*** Bug 125653 has been marked as a duplicate of this bug. ***
*** Bug 128483 has been marked as a duplicate of this bug. ***
Changing priority to 'high' since the number of duplicates is 5 or higher
*** Bug 129974 has been marked as a duplicate of this bug. ***
Hello all, I just discovered this issue. I am happy it has been discussed. Someone above asked for a use-case. Well, displaying formatting marks is simply mandatory in my work (translator). At the moment, while I use LibreOffice for all the text I write and with MS Word files I receive, I cannot use Impress. Even my Computer Assisted Translation tool understands and displays formatting marks from PowerPoint files. It is just crucial for me to distinguish a space from a non-breaking space, or soft and hard returns. It affects the segmentation of text boxes, the formatting of punctuation, etc. Interestingly PowerPoint remove this functionality too. It is one of the most asked questions related to this soft. Time for LO to show the way?
*** Bug 146969 has been marked as a duplicate of this bug. ***