Container format for notes, to allow more functionalities compared to markdown (MD)

I'm coming to you with an idea of a new format for Joplin.

My problem stems from the fact that I'm using and enjoying the way OneNote organizes page - it allows for content to be placed independently; but at the same time I'm limited to their editor.

By introducing a container, Joplin could have several new features:

  • Ability to position elements on page at any place
  • Ability to include in a single page different formats (MD, Asciidoc and wysiwyg-generated HTML to name a few). This would decouple rendering and format from Joplin
  • ...which in turn would handle other limitations like MD tables and image positioning

Details:
XLD1YZ~1


As this is a container format; it is trivially easy to create from/export to a single document. This would also allow to create a pluggable renderer/editor for each content type.

At this point, I am working on a PoC implementation, using yaml as a container (I know, not a perfect format - but this is PoC :slight_smile: )

Question is - would Joplin be interested in adopting a separate format; or would you rather stick to markdown?

Example format:
SoWkIImgAStDuKehIinDLGX8J4zLiB5npiyhISpCIosoirEevb9GW4ZwbvRa00KDqHGa5YieGQKK39L0we4W6gGYDQ_4C1QeEY07g5QX9BMY1AeSAga4L5gBRhoU7XxpzVJGBT3J8za6FpmM-A6RxqVO-5ekXzIy560W0W00

reference from OneNote
image

example.onote (618 Bytes)

Looks nice. Sometimes the added flexibility does come in handy.

At this point for me personally, portability is the most important. Do you have any plans for graceful degradation? What would the export look like?

Sure, this is why I've started with YAML - or any plain text really. The way I'd see it, is:

# sample-file.onote
#  This is a sample file, with metadata omitted for brevity.
outlines:
  # This was created in application
  - metadata:
      type: markdown
    content: |
      # Example type
  # This one was imported - notice original file name in metadata
  - metadata:
      originalFileName: "filename.adoc"
      type: asciidoc
    content: |
      example
  # Sample file without title or original filename
  - metadata:
      type: xml
    content: |
      <document/>

So for degradation:

  • in case of no renderers available, we can always print the plain text for each outline.
  • File in case of YAML example is perfectly readable as plain text; and as such can be manipulated (With e.g. JG, so export script outside of the Joplin could be done easily)
  • In the application itself, I'd see export as action that splits the original file, using the example:
    (After export action)
    • sample-file_Example_title.md // Prefix from note name, then normalized first sentence, then filetype from type
    • sample-file_filename.adoc // This one was imported, so we export almost 'as was'
    • sample-file_1.xml // Either incremented, or maybe UUID? Another option would be to use a trick from the OneNote book and use the first sentence of an outline

Does that answer your question?

I'm still working on a POC and I'll soon be ready to show it off. 95% of it is written with React, so it should be quite portable.

1 Like

do simple things well first. Joplin editor is still so weak now.

In the meantime, I've posted the POC under-way on my GH (Unfortunately, I cannot post links so you have to find it yourself)

github->Venthe/onote

I've originally used VSCode as a host, but to speed up development (And actually decouple from the host) I've switched to dev server completely.

As such, npm ci && npm run editor:serve:web should be suffice to test

I'm developing this for myself - as this is the single thing that keeps me out of Joplin. So either Joplin is interested - I'll be happy to contribute; or I'll keep it as VSCode plug-in.

I need this functionality. :smiley:

Here's the update on the progress: https_github_com/Venthe/onote/tree/rewrite

I'm understanding React now :slight_smile:

  • Outlines:
    • Can be edited
    • Can be created when page is clicked
    • Can be moved via header
    • Can be resized via corner handle
    • Can be resized via side handle
    • Can be deleted by removing all text
  • Renderers
    • Read only renderer can be injected
    • Example Markdown RO renderer implemented
    • Example Asciidoc RO renderer implemented
  • Ribbon
    • Plugin system based on commands connecting ribbon buttons and text manipulation functions; limited by user-defined types
    • Dynamic/extensible categories (Partially, without helper functions)
    • Example bold and italics (working for Markdown only as an example)

TODO:

  • Ability to change outline type
  • Add plug-able read-write renderers
  • Add undo/redo functionality
  • Style example asciidoc RO renderer
  • Optimize performance - remove unnecessary saves
  • Optimize performance - remove unnecessary redraws
  • Implement scale in status bar
  • Implement column/row in status bar
  • Refactor code from POC (Tests, linting etc.)
  • Add helper functions to extensible code
  • Add example WYSIWYG editor for markdown
  • Add example WYSIWYG editor for rich text (HTML?)
  • Add file upload
  • Add editable title
  • Add editable creation date
  • Add new handled type - sticky notes
  • Add keybinds for ribbon commands
  • Support switchable styles
  • Support translations
  • Add dynamic sizes for a ribbon
  • Split the projects to a component/web-app
  • Add export/import of files
  • Add right-click context menu
  • Add support for dynamic styles for a drop-down. (And subsequently, reading the current style)

Known bugs:

  • Undo+redo not working
  • Outline created/moved outside of the screen is not being smoothly tracked by a viewport (scrollTo)
2 Likes