Add ability to combine different formatting.

[C.Kontros]

I'm running Zim .23 in Ubuntu Hardy.

I noticed the inability to combine some formatting. ie: I formatted text with Head1 and wanted to then underline it. Couldn't be done.

I would simply like to be able to do formatting like this.

Thatnx for the awesome little app.

[Jaap Karssenberg (jaap.karssenberg)]

Can you explain why you want this, give a use case for this. For example do you want to highlight a certain header to get more attention than other headers or do you want to change the style of all level 1 headers ?

[C.Kontros (coryisatm)]

I want to be able to format text with Head1 and underline it. It wouldn't apply to a Head1 formatted text.

[Jaap Karssenberg (jaap.karssenberg)]

From the design I try to have formattings with functional properties, instead of layout properties. What I mean by that is that a head1 may look different when exporting to e.g. html but still has the role of being a heading.

In this case it is not clear to me if you want to add a new formatting type which is rendered big, bold and underlined, or if you use underline in a different way. Implementing this is not as easy as it sounds because the current code always assumes that styles do not overlap, so I would like to have a good understanding of the problem at hand before starting to hack away.

[C.Kontros (coryisatm)]

Yes. The styles "overlap" would be a good way to put it.

In MoinMoin for instance, I can make the text large *and* underline it. Thats one thing I would like to do.

[Jaap Karssenberg (jaap.karssenberg)]

Allowing more flexibility in styles needs serious design work, keeping status "incomplete" until more clear on how to approach this. E.g. we can allow styles to allow overlap or we can add custom styles. Either way will need a lot of work in the GUI part as well as a solution how to handle styles in the different backend formats.

[dotancohen (dotancohen)]

I would suggest that this be implemented as a "styles" feature, in that the user defines the styles used for different types of text (headings, links, plain text, strong text, etc.).

[Jaap Karssenberg (jaap.karssenberg)]

See bugs #271916 and #271918 for bugs due to the difference between 'styles' and 'formatting'.

[Jaap Karssenberg (jaap.karssenberg)]

@dotancohen, in reaction to bug #272516 :

The reason it ended up like this is that I want to think in terms of styles, not formatting. So each piece of text has only one style. Instead of "bold" and "italic" I want to think of "strong" and "emphasis".

That "strong" is rendered as bold should be a configuration option, this could look different for exported formats due to e.g. style sheets. You might as well choose to have all "strong" text rendered in red. (Actually you can do this in zim right now, see the manual page on styles for the configuration options.)

So initial versions of zim had "strong" and "emphasis" instead of "bold" and "italic", however I found that this scared away a lot of users because people are indeed used to seeing icon buttons for "bold" and "italic" and have them do exactly as they expect. So I tried to retain the styles feature but added the familiar icons and names.

I agree the result is an implementation which is not entirely in line with other text editors.

My proposal is to have a "styles editor", which is defined in bug #230160, and allow adding new styles, (which I track with this bug). Maybe rename back to "strong" and "emphasis, but for sure maintain the current icons.

The result should be that "bold" and "italic" will still be mutually exclusive, but you can add a new style for "bold+italic".

I really want to stick to a single style per piece of text because this greatly reduces the complexity for source formats like wiki, xhtml, pod, etc. Also conceptually it feels right to de-couple the function of a style and the rendering of that style.

[dotancohen (dotancohen)]

> The result should be that "bold" and "italic" will still be mutually
> exclusive, but you can add a new style for "bold+italic".

In that case, then I recommend that Zim internally switch text to the "bold+italic" style when a user tries to apply both to a string. That way, the application is consistent with other applications from the users point of view, yet it has the defined style which can be modified (CSS for instance) on export from a technical point of view.

In any case, I agree with the separation of semantics and presentation.

[dotancohen (dotancohen)]

I apologize for being pedantic, but Zim breaks the Gnome HIG so long as Bold and Italic are handled as mutually exclusive styles. Here is the relevant HIG page:
http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en

"Make your application consistent with itself and with other applications, in both its appearance and its behavior. This is one of the most important design principles,..."
    - Gnome HIG

[nomnex (nomnex)]

I concur. I was looking for Bold + Italic. The bug report advices to create a new style. I have to read a bit of doc to create the style. that's not that bad in the end, but time consuming for a quick edit.

[nomnex (nomnex)]

#8 > I really want to stick to a single style per piece of text because this greatly reduces the complexity for source formats like wiki, xhtml, pod, etc. Also conceptually it feels right to de-couple the function of a style and the rendering of that style.

I should have read better. Bold + Italic, never mind. I begin to understand the zim concept and I like it.

[manny (estelar57)]

hmm, i think zim also needs this feature.

in many cases a writer will need to bold, italic, underline and/or highlight, to differentiate from other texts and emphasize priority.

other editors like cherrytree, notecase, basket and even tomboy/gnotes allow you to combine different formats. People are also used to this in all the office editors: word, OOo writer, abiword, etc.

the biggest problem that i see, is that even trying to edit the source, wont allow these changes to reflect in zim

this format limit issue, may also lead to other bugs, like:
https://bugs.launchpad.net/zim/+bug/594239 (Applying strike format to links does not work)

so, unfortunately the only one limiting the user by omitting this, is zim

This would be a most welcome usability option that would allow many users to not be driven away from zim, because of something so basic these days, this great project has been overlooked or underrated.

[Frank Uebel (fuebel)]

As links are also defined by tags, we currently can not have bold links, as it seems. I was playing with code like this:
buffer = textview.get_buffer()
tag = buffer.create_link_tag(word, pagename)
buffer.apply_tag(tag, start, end)
That works, as long as there is only plain text there to begin with. If there is already a formatting (bold, underline, etc) on these words, at first, it is rendered correcly (link in bold!), but as a refresh of the page kicks in, the whole line, starting from the link-tag, is deleted. Deleting the text first and then inserting a completely new link works and creates a regular href in the bold text, but the href itself is not rendered in bold.
I did not look into this yet, what exactly happens internally, but it might just be a simple problem with the parser, that prevents combined tags.
My 2ct, though.

[smu (smu)]

I would like to vote for this too. The bold links or links with strike formatting is a good example, why the combination of could be useful. Currently, the target information of a link is removed, when the strike formatting is applied. Removing this format does not result in a recreation of the link.

I come over another (maybe weaker) example today. I am managing quotes with zim and prefer to use italic formating for the quote. Then, highlighting an important sentence is not possible.

in short: combining different format in zim would be very useful feature.

[Jaap Karssenberg (jaap.karssenberg)]

From duplicate:

"""
Applying italic format to superscript sequence removes superscript

Steps to reproduce:

1. Enter a test sequence (e.g. test2) and format parts of it as superscript
2. Select the sequence and apply the italic format

result:
- The superscript formatted part looses his formatting

expected behavior:

- The sequence should be formatted italic, but the superscript part should be conserved.
"""

[Jaap Karssenberg (jaap.karssenberg)]

From duplicate Bug #704386:

I'm currently switching from my old moinmoin standalone wiki to Zim. Therefore I've modified a converter tool which originaly converts the moin syntax to dokuwiki.

My problem is, that mixed attributes are not supported by Zim. Is it possible to allow a mixture of bold+italic or bold+verbatim?

---

OK, as fas as I understand, the GTk widget is able to show mixed
attributes, but your data model isn't able to handle it?

By the way. I dont' think that renaming bold to strongs solves the
"problem". For example, one of my use cases are verbatim blocks with
attributes to emphaze some parts. So in this case, even the style
editor doesn't solve the problem.

One can argue that mixing bold and italic isn't realy necessary. But
at least with use cases like so one mentioned above, this
argumentations fails. ;-)

Nevertheless, I'm happy with ZIM and resume converting the several
hunderd pages from moin.

[Jaap Karssenberg (jaap.karssenberg)]

Thinking this over I think I have to revert my previous view point on this. So far little has developed that makes use of treating formatting as a functional markup in zim. So may as well go the way users expect the tool to work and allow some combinations. But need to come up with a bit formal definition of what is allowed.

Would say that headings and verbatim remain functional, so are not allowed to combine with other formats.

Emphasis and strong would be renamed back to bold and italic. Mark remains as-is because I can not convert it to proper underline without breaking existing notebooks.

Strike, mark, bold, Italic, sub- super- script and links should be allowed to combine. Order of precedence (when needed) as listed in the previous sentence.

I would like to put a restriction on links that they can only have a single format for the whole link. This in order to avoid breaking a link when formatting is applied to only part of it.

[joede (joerg-desch)]

Great News. Thanks for implementing mixed formattings.

I'm glad about your decision, even if mixing bold/italic with verbatim would be more than welcome. ;-)

[dotancohen (dotancohen)]

Great move, Jaap! I beg to differ on the Mark/Underline point, though, you could solve it like this:
1) Give the Mark style a different keyboard shortcut and icon.
2) Two versions down the line, create a new style called Underline.
3) Give the new Underline style the proper icon and keyboard shortcut.

[smu (smu)]

On Fri, Jan 21, 2011 at 02:16:31PM -0000, Jaap Karssenberg wrote:
> Thinking this over I think I have to revert my previous view point on
> this. So far little has developed that makes use of treating formatting
> as a functional markup in zim. So may as well go the way users expect
> the tool to work and allow some combinations. But need to come up with a
> bit formal definition of what is allowed.

I really like this descision!

> Would say that headings and verbatim remain functional, so are not
> allowed to combine with other formats.
>
> Emphasis and strong would be renamed back to bold and italic. Mark
> remains as-is because I can not convert it to proper underline without
> breaking existing notebooks.
>
> Strike, mark, bold, Italic, sub- super- script and links should be
> allowed to combine. Order of precedence (when needed) as listed in the
> previous sentence.
>
> I would like to put a restriction on links that they can only have a
> single format for the whole link. This in order to avoid breaking a link
> when formatting is applied to only part of it.

these rules make sense, but I would make an exception for the strike
format. I think it should be possible to apply strike to every text
element of a page, including verbatim and headings, without changing the
format (besides font colour). And if the strike format is removed, the
previous format should be dispayed again, so that nothing changes, when
strike format is toggled.

I use the strike format quite often in zim, to "remove" finished tasks
or old information. From time to time, "old information" becomes
important again, and then it is cumbersome so reapply all previous
formats.

what do you think?

best regards,

 Stefan

[Uncle Pedro (peter.a.h.peterson)]

I also want to express my interest in this feature. As others have mentioned, users expect editors to work this way -- not just Word, etc., but even Tomboy and MoinMoin support format combinations like this.

I personally do not feel a need to apply formatting to headings, and respect the "functional" nature of them from a conversion and import/export perspective.

On the other hand, I do think that applying formatting to verbatim is valuable. While it's not a deal-breaker for me, my use case is that I use Zim for research notes, and I often copy output from a terminal into a document as "verbatim" to preserve formatting. However, I regularly would like to highlight particular text or values from the output for reference. "Bold" is one obvious way to do that -- another way would be to change the color or background of the text (a feature that I haven't found yet, if it exists). This is also something that can be done in other editors, so while I respect the underlying philosophy and design that makes this tricky, I don't think that it's that strange of a feature request.

[sojusnik (sojusnik)]

Signed!

[andré (andr55)]

It would be nice to see mark and underline treated as separate formats.
Currently the usual wiki code for underline is used for mark, which displays as yellow background highlight.
Similar to earlier suggestions, you could introduce a separate code for mark.
But I would suggest an option "treat underline as mark", initially on by default. Those users that wish to use underline would turn this off.
You could also/alternately include an option to "convert mark to new internal format".
In any case I would use underline in place of yellow highlight most of the time.
But the highlight, being highly visible, is very useful for certain exceptional cases.

IMHO, requiring links to have a uniform format is not only good from the programming side, it also is visually more coherant.

[Jaap Karssenberg (jaap.karssenberg)]

Andre,

This report is not about separating mark and underline, that is a different
discussion.

Regards,

Jaap

On Wed, Nov 14, 2012 at 5:18 AM, andré <email address hidden> wrote:

> It would be nice to see mark and underline treated as separate formats.
> Currently the usual wiki code for underline is used for mark, which
> displays as yellow background highlight.
> Similar to earlier suggestions, you could introduce a separate code for
> mark.
> But I would suggest an option "treat underline as mark", initially on by
> default. Those users that wish to use underline would turn this off.
> You could also/alternately include an option to "convert mark to new
> internal format".
> In any case I would use underline in place of yellow highlight most of the
> time.
> But the highlight, being highly visible, is very useful for certain
> exceptional cases.
>
> IMHO, requiring links to have a uniform format is not only good from the
> programming side, it also is visually more coherant.
>
> --
> You received this bug notification because you are subscribed to Zim.
> https://bugs.launchpad.net/bugs/239854
>
> Title:
> Add ability to combine different formatting.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/zim/+bug/239854/+subscriptions
>

[Jaap Karssenberg (jaap.karssenberg)]

Also see bug #594239

[Sparhawk (sparhawkthesecond)]

I have a usage case that I ran into within several minutes of using zim. I am a biologist, and species names are always in Latin and hence *must* be italicised (e.g. //Homo sapiens//). If I want to put a species name in a heading, it should be italicised, and the inability to do so makes me convulse uncontrollably. :o

[Hector Z (m8r-15x1tp)]

Sparhawk's biology case also happened to me, but when I had a bold text. Bolding a text remove the italics of the species name.

I can't remember right now, but there were cases when I needed bold italic for some strong reason or bolded links.

[lalebarde (l-alebarde)]

Looks like this has not been implemented yet (v 0.65)

[DIG (dig)]

I am using zim 0.65-2, and my use case is this:

I have an output from the console program, this output is formatted using monospace font. I need some parts of that output to be marked (by yellow background is OK). But when marked, it immediately disrupts the formatting of the line with marked fragment.

So, I also want to express my interest in this feature: combined verbatim and mark formatting.