Feature Request: RTL Content Support and Custom Fonts

[voyager-5]

I would like to request two content-related features:

1. RTL (Right-to-Left) content support

   • The application UI should remain LTR.
   • Only the content area should support RTL languages such as Persian, Arabic, and Hebrew.
   • Notes, tables, lists, code blocks, and other content elements should render and behave correctly with RTL text.

2. Custom font support for content

   • Allow users to choose custom fonts for note content.
   • This should apply only to the content/body text and should not affect the application's UI fonts.

These features would greatly improve the writing experience for users who work with RTL languages and prefer custom typography for their notes.

[brufdev]

It's not something I would use myself, but both seem like good suggestions. I'll need to investigate about this and see what I can do.

[simonlpaige]

@voyager-5, these features would indeed improve the experience for RTL users. I've been looking at the rendering pipeline to see what would be involved.

For RTL support, the key challenge is that the current Markdown rendering (likely using league/commonmark or similar) applies dir="auto" only at the block level, but RTL content in mixed LTR/RTL documents (e.g., Arabic text inside an English note) needs per-paragraph or per-inline handling. You'd want to wrap rendered content in a container with dir="auto" and apply unicode-bidi: plaintext via CSS, which lets the browser determine direction per paragraph based on the first strong character. The existing content div in resources/views/ would need this CSS class, plus a check in the rendering logic to avoid breaking code blocks (which should stay LTR). Tables also need dir on each <td> for mixed content.

For custom fonts, the cleanest approach would be to store a per-user or per-note font preference in the notes or users database table (a content_font column), then inject a CSS variable like --note-font-family into the content wrapper. The existing theme system in app/Http/Controllers/ already handles per-user CSS overrides, so you could extend that pattern. Avoid loading external font files in the backend—let users specify system fonts or self-hosted URLs via a settings field.

Both features would be self-contained in the frontend layer (CSS/JS + a small DB migration), with no changes to the filesystem vault structure.