xournalpp / xournalpp

Xournal++ is a handwriting notetaking software with PDF annotation support. Written in C++ with GTK3, supporting Linux (e.g. Ubuntu, Debian, Arch, SUSE), macOS and Windows 10. Supports pen input from devices such as Wacom Tablets.
https://xournalpp.github.io
GNU General Public License v2.0
10.65k stars 782 forks source link

Rich text support #729

Open PellelNitram opened 5 years ago

PellelNitram commented 5 years ago

I had the following idea which would make Xournal++ even more competitive to other (commercial) software.

The idea is rich text support. While I am not all sure if that's the right wording, here is what I thought of: When typing text, it would be amazing to have lists and word-wise formatting (such as this). I call it "rich text support" because I know that RST or Markdown introduce a simple syntax that can be rendered to look like formatted text and lists upon rendering.

Neither do I have an idea how much work it is to implement it nor do I know what you think of it :-).

What I do know is that it would make Xournal++ even more competitive and that I would enjoy the feature. The reason for the latter is that I, amongst others, take study notes with Xournal++ and end up using "x)" or "*" as bullet points because I use lists a lot.

andreasb242 commented 5 years ago

@PellelNitram I fully agree with you. And when I started Xournal++, I even thought I'll add Rich Text Support.

But it will be incompatible with .xoj, at that time this was the killer, I woulden't brake the support. But now we have .xopp, which is anyway incompatible, we have a .xoj export, which removes all stuff which is not compatible, so this will not be an issue anymore.

And because I would add RTF, I uses from beginning on Pango. So technical Xournal++ already is ready for RTF, if you select Text, we set the background Color, this is not a selection!

So first: Load / Store needs to be implemented, and the .xoj Export, needs to be implemented. And there needs a good UI Solution, a popup-toolbar or something like this, it does not fit the current customize toolbar. But therefore it's much less work, than it may look like.

But don't expect it tomorrow, it's still complicated.... And it's definitive a hard task, which takes time....

PellelNitram commented 5 years ago

Oh, that's amazing news to hear!

I will keep my eyes open and once I find a task that I can solve, I will create another PR :-).

andreasb242 commented 5 years ago

@PellelNitram If you need help you can ask in the issues, we usually respond.

But this task is probably a really bad start ;-) Definitive not a beginner task.

nicolae-stroncea commented 4 years ago

I think xournal++ could provide a lot of these features through Markdown Integration. Markdown already provides ordered and unordered lists, emphasizing, italicizing and crossing selected words , texts of different sizes through headings, links, horizontal rules, code format, block quotes). Many people take notes with Markdown, and it is a very popular tool. Users could type in Markdown and xournal++ would automatically compile it, in the same way as it does with Latex. I was looking into what would be the easiest way to integrate this.

I found that Latex has a markdown package and we can wrap the user input into: \begin{markdown} and \end{markdown} and anything that the user types as Markdown gets converted to Latex equivalent. The advantage here is that you can type notes in Markdown style, and use Latex equations at the same time(by putting them in between $$).

This gives the best of both worlds, as the user can use fairly easy syntax for a lot of common text styling.

I'm currently working on providing that as a separate Latex template(there's a couple of things that need to be ironed out).

Technius commented 4 years ago

Users could type in Markdown and xournal++ would automatically compile it, in the same way as it does with Latex. I was looking into what would be the easiest way to integrate this.

This works as a temporary solution, but not everyone has LaTeX installed (esp. Windows users). Ideally, we should bundle a Markdown renderer.

I very much support the idea of allowing Markdown in text. The easiest way would be to include the CommonMark reference implementation, which has no dependencies. However, the output includes arbitrary HTML, and pango only supports a subset of HTML.

There's also a few problems:

  1. Backwards compatibility: existing text annotations have no notion of rich text and may be rendered differently with markdown. For example, what if I was taking notes about HTML?
  2. Making pango work with HTML: we could try only allowing some tags to be translated and leave the rest as literal. For example, we could ignore images.
  3. UI, as @andreasb242 mentioned.
  4. Links: currently, we have no notion of a "link" object. Ideally, these links should also be clickable in exported PDFs.
nicolae-stroncea commented 4 years ago

For backwards compatibility, would creating a new Text widget work, similar to how currently you have a widget for normal text, and one for Latex? So if you use the new text widget it gets formatted properly using Markdown, whereas the old one leaves the text as is

Technius commented 4 years ago

For backwards compatibility, would creating a new Text widget work, similar to how currently you have a widget for normal text, and one for Latex?

We could do that, but then opening a document with the new text widget on an older version of Xournal++ will cause the text widget to disappear (since the older version cannot understand the widget) without warning. This breaks backwards compatibility in terms of Xournal++ version.

It would be much easier to handle these backwards incompatibility problems in the new file format, where we can 1) include file format version checking code from the get-go and provide warning popups when loading files that are too new; and 2) automatically migrate older files, avoiding file format backwards compatibility.

bhennion commented 4 months ago

Closing in favour of #3408

rolandlo commented 2 months ago

Closing in favour of #3408

Looks like this issue was closed prematurely; #3408 is a PR, not an issue, although it contains some discussions.