Bug Hunting Session
Bug 46028 - [RFE, FORMATTING] Permit associating an image/symbol/text label to a paragraph style
Summary: [RFE, FORMATTING] Permit associating an image/symbol/text label to a paragrap...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Styles-Paragraph Writer-Enhancements
  Show dependency treegraph
 
Reported: 2012-02-14 02:17 UTC by Nicolas Mailhot
Modified: 2017-12-18 04:12 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Mailhot 2012-02-14 02:17:45 UTC
It is very common in technical documents to have symbols or text labels floated to a side of special paragraph (typically, warning-like symbols for warning notes, keyboard symbol for console examples, etc)

Those symbols are repeated many times in such a document and associated with specific paragraph styles. However it is not possible to declare them in paragraph styles right now, forcing manual styling of every instance (which is hell when the graphical charter changes and every such occurrence needs restyling)

It should be possible to specify images, symbols or text labels to attach automatically to one side of a paragraph with a specific style, just like it is possible right now for paragraph borders.
Comment 1 sasha.libreoffice 2012-05-18 04:49:51 UTC
Thanks for new idea
What if use for such purpose buletted list? And instead of bulled choose warning-like symbols or other needed things.
(Format->Bullets and numbering, then on tab "Graphics" select any cell, then on tab "Options" press button "Graphics Select" and choose needed picture, then specify Width and Height of picture.)
Comment 2 Nicolas Mailhot 2012-05-18 08:46:58 UTC
Typical symbols have two-three text lines of height, so trying to insert them via bullets will only disrupt text flow (also bullets are very specific on the side they want to be while such symbols can occur on any side/corner  of the text paragraph depending on styling wishes
Comment 3 sasha.libreoffice 2012-05-19 02:39:32 UTC
Thanks for additional information. Another important thing: ODF format. If it not allow such thing, then we can not save such thing into document.

PS: IMHO this functionality resembles Drop Caps, but with ability to use image instead of character.
(I just tried to place image into paragraph as character, and the enabled dropcaps. But Writer not count image-anchored-as-character as character for Drop Caps. May be it is a bug?)
May be we should ask developers to improve Drop Caps? It may be more easy to implement and for users more understandable how to use and where to search for such functionality.
Comment 4 Nino 2013-10-20 08:44:02 UTC
IMHO this is a valid RFE, so changing status to NEW.
Comment 5 Owen Genat (retired) 2013-10-20 11:03:26 UTC
There is a related AskLO thread about this particular feature, where I offer some workarounds:

http://ask.libreoffice.org/en/question/21691/writer-how-to-associate-a-margin-icon-to-a-paragraph-style/

If this is implemented through the use of an associated frame style, then bug #44597 may end up being related. The inclusion of "text label" (a.k.a. marginalia) in the title of this bug also supports this relationship.
Comment 6 Zenaan Harkness 2016-08-29 12:06:54 UTC
I call this 'subroutineing' - styles are appropriate for placement, and other properties such as font, size, anchoring (possibly), but not for content, although list styles do specify certain content for example.

Arguably, styles could support content to provide this subroutineing capability. I can easily imagine a "Footer" style which is both a paragraph style, but also contains the footer text. Come to think of it, footer text is evidently
 "somehow attached"
in Page styles, but Page styles modify dialog box does not provide for direct editing of this content - the WYSIWYG "View -> Normal" view is more than able for such editing, and quite arguably the correct place for such editing.

There is a real argument however, to make these
 style <--> content
connections more "visible" in the UI, both to increase contextual awareness for the end users (that's us :) as well as to promote consideration and thinking about UI and UX flows.

For example: Page style (or other styles?), when Footer or Header is enabled, --really should-- :
a) display a mini preview of the current footer for that Page style, and
b) provide a CLEARLY VISIBLE note, to tell the user where to go to actually create content which will thereafter display as that preview

Since page styles have attached content (header and footer - and these should have previews), and list styles have embedded content (and sort of have previews), LO SHOULD have frame styles which include embedded content, and provide a preview, to solve the OPs problem.

Yes, this would be a very nice feature - and the if there is no dissent, and a developer can say "yes, that makes sense" then the subject title of this bug could be updated to, e.g.:
[RFE, FORMATTING, UX, UI] Allow frame styles with attached content, and properties dialog preview

ALSO, in MSWord (since at least WordXP), para styles may have an attached frame style: What this means is that for marginalia of any sort (special character, image, text etc), one can simply insert it as a paragraph, then double click on the pre-designed paragraph style, and voila, that para is perfectly placed as a marginalia to the subsequent para. Another feature I guess..

Might also need a search and replace option to -avoid- frames content (not sure if this currently applies), or to avoid frames which contain default content (like footer) - these UX and UI details really need to be handled well, e.g. see bug #62603.

Similarly, bugs like bug #62071 must be carefully considered in relation to the above proposed enhancements.

Next question: should we create a series of "enhancement request" bugs to detail these enhancements (I don't mind doing that if it's "the right" thing to do), or just keep this current bug alive for these various enhancement requests? I would appreciate someone knowledgeable chiming in on this one; thanks heaps.