Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enormous PDFs Exports #1217

Open
sortedcord opened this issue Sep 14, 2024 · 2 comments
Open

Enormous PDFs Exports #1217

sortedcord opened this issue Sep 14, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@sortedcord
Copy link

sortedcord commented Sep 14, 2024

I have a rnote file that mainly consists of ink and a small picture (5 pages) and when I export it directly as a PDF, rnote created a PDF file that is 12Mb in size, however, if I export it to Xournalpp and then export it to pdf using XournalPP the file size only comes out to be 2Mb in size while being exactly the same as the previous export? Also I wanted to report that the PDF file exported by rnote is really laggy to view on other PDF viewers, especially when scrolling to the next page, there is a significant lag and the pdf viewer (browser) almost freezes up.

Screenshots

Desktop (please complete the following information):

  • OS: Endeavour OS
  • App Version: Rnote v0.11.0
  • Installation Source: Archlinux Community Repo
  • Desktop Environment: KDE Plasma 6.1.4
  • Display Server: Wayland
  • Input Source: Mouse and Keyboard, External Graphics Tablet

image

file in question:
test.zip

Why is this happening? Is there anything I can configure to bring the size down without having to use Xournalpp to export it to PDFs?

@Doublonmousse Doublonmousse added the enhancement New feature or request label Sep 15, 2024
@Doublonmousse
Copy link
Collaborator

Seems like xournal does some sort of compression when creating the output (maybe some quantization of points based on the dpi ?).
Comparing the two pdf and you see that there are visible differences

image
(xournalpp on the left rnote on the right)

So that probably accounts for the size difference between the two. Does removing the background in rnote (and exporting a pdf version without the background) helps with the reader ?

There's probably a handful of things that could be improved in rnote regarding pdf size

  • Try to see what xournalpp is doing and matching it (lossy compression of the strokes). Imo this should stay optional.
  • See what's possible to do with stroke simplification (find a curve with less points/data needed to construct it that stays close to the actual stroke) : no idea how feasible that is (what algorithm exist today ? for what performance cost ?) but at the very least having a compression that stays "smooth" seems more doable this way

And another part may be possible at the ink modeler stage. Currently the size of the file (and by extension the pdf) is linear in the number of pen events. But that's device dependent (refresh rate for pens may be between 60 and 480 Hz) so writing slowly means a larger file !
Hence the following may be possible

  • Have heuristics in place to discard events that are too close to the previous one
  • Have the smoothing algorithm serve as a compression step as well (and produce potentially less events than the number of events sent by the pen)

Maybe an optional rasterized export (export to png or jpg) would allow for smaller/easier to read pdf at the price of loosing the vectorized aspect (seeing pixels when zooming instead of the smooth vector paths currently)

@Intranox
Copy link

Sembra che xournal esegua una sorta di compressione quando crea l'output (forse una quantizzazione dei punti basata sui dpi?). Confrontando i due pdf, si vede che ci sono differenze visibili

immagine (xournalpp sulla sinistra rnote sulla destra)

Quindi questo probabilmente spiega la differenza di dimensioni tra i due. Rimuovere lo sfondo in rnote (ed esportare una versione pdf senza sfondo) aiuta con il lettore?

Ci sono probabilmente alcune cose che potrebbero essere migliorate in rnote per quanto riguarda le dimensioni del pdf

  • Prova a vedere cosa sta facendo xournalpp e a confrontarlo (compressione con perdita dei tratti). A mio parere questo dovrebbe rimanere facoltativo.
  • Vedi cosa è possibile fare con la semplificazione del tratto (trova una curva con meno punti/dati necessari per costruirla che rimanga vicina al tratto effettivo): non ho idea di quanto sia fattibile (quale algoritmo esiste oggi? A quale costo in termini di prestazioni?), ma almeno avere una compressione che rimanga "liscia" sembra più fattibile in questo modo.

E un'altra parte potrebbe essere possibile nella fase di modellazione dell'inchiostro. Attualmente la dimensione del file (e per estensione del pdf) è lineare nel numero di eventi penna. Ma questo dipende dal dispositivo (la frequenza di aggiornamento per le penne potrebbe essere compresa tra 60 e 480 Hz), quindi scrivere lentamente significa un file più grande! Quindi potrebbe essere possibile quanto segue

  • Avere delle euristiche in atto per scartare gli eventi che sono troppo vicini al precedente
  • Far sì che l'algoritmo di smoothing funga anche da fase di compressione (e produca potenzialmente meno eventi rispetto al numero di eventi inviati dalla penna)

Forse un'esportazione rasterizzata opzionale (esportazione in png o jpg) consentirebbe di ottenere un PDF più piccolo/più facile da leggere, al prezzo di perdere l'aspetto vettorializzato (visualizzazione dei pixel durante lo zoom invece degli attuali percorsi vettoriali uniformi)

I certainly have a lot of knowledge about this, however it would be nice to have an option in rnote to choose the quality of the pdf export. I also noticed that, especially when the rnote files are quite large, the pdf export takes up a lot of space.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants