[Feature] Support page fomatting options for docs

[dhda]

Is your feature request related to a problem? Please describe.
When I'm writing I'm very sensitive to how the document feels and looks. Writing is an expressive art for me that goes beyond just the linear text of it, so I like to be able to tweak things so that all feels good. With computers this is the joy and benefit of word processing beyond just plain note taking (never thought i'd describe word processing that way 😆), and it's why I'm excited about Cryptee right now over other potential encrypted solutions! It's more like sculpting than anything.

Right now Cryptee automatically scales the document width and margins based on the viewport's width–this mostly works really well! Unfortunately, for full-screen-width browser windows on desktop, the document keeps getting really really wide until the lines of text get all the way stretched out and hard to read. I find that my eyes can't even focus and track the text when the lines are that long. I can pop Cryptee out into its own narrow window, but often I'll be rapidly tabbing back and forth between a tab for writing and a tab for research, or just like the convenience of having a tab for writing within the same browser window, so that doesn't cover all my use cases.

Describe the solution you'd like
A maximum page width would go a long way as a simple, minimal fix. The doc editor right now feels like it's occupying some kind of middle ground between pure browser based editing and print/paper document editing (which is what word processors classically target) so I'm trying to envision flexible solutions. Ultimately I'd love to be able to specify the page width and margins for my document to have a consistent experience across browser windows that are wide enough (and then for smaller viewports scaling down as Cryptee currently does). Margins especially have a huge impact on readability and the whole feeling of a doc. My expression gets channeled in totally different ways depending on this stuff.

I'm coming from Google Docs, which has gone all the way down the path of digital sheets of paper with a fixed layout. That would feel strange in Cryptee where it's at now (though reading other requests on here it sounds like you may be headed more in that direction?), but having as option for some of "paper width" or "hybrid print view" would be nice.

I'd also love to be able to configure paragraph formatting like line spacing!

Additional context
Thanks for the work you're doing! I'm really excited to see how Cryptee grows.

[johnozbay]

Hey there! Thank you for your kind compliments!

I'm sooo glad you've asked! If that's okay with you too, I'll write a loong answer here, and link other users who are looking for the same feature here.

I'm happy to say this is already on the way! 🎉 (screenshots below) We first had to finish & release tables to make sure that table-width scales with the document-width as expected. (I'll talk about why this is incredibly important and relevant shortly below)

Now that tables are ready, we're working on all types of page formatting options. Margins, paper-sizes, multi-page editing, print-accurate editing, etc. And the way we'll go about this is going to be a toggle switch, where you'll be able to switch from a continuous-scroll/digital mode, to paper-mode.

My personal opinion on this is quite strange (and perhaps a bit too progressive). – My opinion is that thinking of documents (or typed out information) in paper-sizes like A4 (defined back in 1786) is a rather outdated way of dealing with the vast amounts of information we have to consume & author in the digital-first era we live in. Especially because 99% of the documents we author are typed digitally and consumed digitally. But for historical reasons, [strangely] most people still use paper-sizes not just while authoring them but also while exporting their documents to PDFs. 📜

When I asked friends and colleagues why they do this, they said this allows them to refer to content on specific page numbers. Which makes sense – but the concept of a page in and of itself is a historical concept, and we can actually easily link to content / chapters in PDFs, and we don't even need page numbers anymore.

In addition, funnily enough, if we valued paper sizes more vs the content itself, we would all instead use our monitors vertically! Think about it. All websites have massive margins on both sides and contents are often centered to make things easier to read. Most websites are scroll-down (not side-ways) and we spend most of our time scrolling down while writing documents or reading them. It's crazy. And the best part is that, the first computer monitors used to be vertical! Because they were used by copywriters & designers for print!

But somehow, somewhere along the way, we moved from vertical monitors to horizontal monitors we use today. Presumably due to less people reading, and more people using computers for wide-screen media consumption like movies / videos. (For example most of team Cryptee uses monitors vertically for coding)

So the solution I'm working on for Cryptee will have all the historically good stuff in it, but also have some nice-futuristic touches.

1. Editor will have a fixed width, in relation to the font-size. So you won't have to worry about content looking different on different screen sizes. Similar to Google Docs / Word.

2. Editor will have an infinite scroll, (like the way it does right now) and will by-default work in this mode. (Like the way it does right now) But also an optional page-editor mode, which will artificially split up/display the infinite-scroll content in the selected page size. Also similar to Google Docs / Word etc.

Here's how these two things look like in our experimental alpha version so far :

3. We had to build tables first, because long tables will exceed a single page's height, and would then need to be broken into multiple pages. So I thought it's best to make sure the code for tables is ready for all this before we moved onto dealing with paper-sizes. 📄

4. What's taking time is that, as you can see in the screenshot of our experiment – depending on the page size you choose, and your display's resolution, this approach leaves lots of extra room on the sides of the document, that could be much better utilized. But the editor is currently programmed in a way that it slides out to reveal more content if you move your mouse outside of the 'paper'. Which in many screen resolutions will be pointless.

5. Having a print-ready-mode vs a digital-mode will also allow having dark-mode in the editor itself ( which right now is not possible precisely because of PDF & print-related issues )

So while the code for fixed-page-size-editing feature is pretty much ready, I'm re-designing bulk of the editor and Cryptee Docs in general to make things look and function meaningfully better, and with it, a lot of amazing changes are on the way.

I'd even dare to call this Cryptee Docs v2.0 – because that's how many cool features & design changes are on the way. 😎

So like you mentioned, it'll be a hybrid-print-view, and I can't wait to talk more about it as we move forward with the design & development.

In the meantime, please write all the ideas / features / changes you'd like to see, and we'll make it all happen!

Hoping all this makes sense! ✌🏻

All the best,
J

[dhda]

Thanks for your delightful reply! I definitely hear you about the strangeness of working on computers and still trying to replicate dead tree paper pages (which is probably more strange than your opinion on it), and I appreciate you approaching your design with that perspective. When I had an external monitor I would always use it vertically for reading and coding, and I can't help but feel so cramped on widescreen monitors after that. I'm laughing looking at the picture of the radius! Computers have taken some strange veering turns from some of their early roots.

I'm excited for all that's coming with Cryptee Docs and looking forward to it.

One specific feature that I've been wanting is the ability to set the default font for a doc. Right now changing the entire font for document only applies to the content that's already there, and any new text that gets entered on a previously empty line, or on a new line preceeding an existing paragraph, just uses the default font instead of the font that I set for everything else. I have a journal document that I append new entries to the top of, and it makes using custom fonts wildly frustrating when I have to cmd/ctrl+A everything and fiddle with formatting to get the text to match whenever i write something new. (maybe that's a bug, because it works as expected when adding text to a new line after existing formatted text...)

[johnozbay]

Just to give a quick update,

In v3, we've shipped parts of this, it's work in progress and hidden at the moment 😅

web-client/source/imports/app/docs-panel-pagesetup.kit

Lines 1 to 48 in 3404467

	<div class="panel white" id="panel-pagesetup" name="Page Setup">
	<small>mode</small>
	<p class="wide">continuous</p>
	<small></small>
	<p class="wide gray">paper / print</p>
	<b></b>
	<b></b>
	<small>size</small>
	<p>a4</p>
	<p class="gray">a3</p>
	<small></small>
	<p class="gray">us letter</p>
	<p class="gray">us legal</p>
	<b></b>
	<b></b>
	<small>orientation</small>
	<p class="wide">portrait</p>
	<small></small>
	<p class="wide gray">landscape</p>
	<b></b>
	<b></b>
	<small>margins</small>
	<small>top</small>
	<input class="darkback" type="text" placeholder="25mm">
	<small></small>
	<small>bottom</small>
	<input class="darkback" type="text" placeholder="25mm">
	<small></small>
	<small>left</small>
	<input class="darkback" type="text" placeholder="25mm">
	<small></small>
	<small>right</small>
	<input class="darkback" type="text" placeholder="25mm">
	</div>

Here's how it looks like :

If you've got any feature ideas, feel free to share it in this thread!
We'll try and as many of them as we can before we release the first few print-layout features!

This thread is also related to #99, since how these page-setup boxes will show depends entirely on how we move forward with the side-bar.

Excited 🎉

[johnozbay]

Hi there, we're making steady progress towards bringing this feature.

We're about to ship line spacing (a component we need to ship before we can ship paper-mode), and we're testing it in beta now. Check this out : #89 (comment) test it out on beta if you can, and let me know what you think 🎉

[johnozbay]

Hello there!

I cannot begin to describe how happy I am to be writing this comment and closing this issue, as I think we've made history to make this possible.

Turns out there's not a single open-source, wysiwyg rich-document editor that supported print/paper-mode editing. Not even any third-party JS libraries etc. So Cryptee is now officially the very first – as far as I can tell from my limited research –

I can write an entire 100 page long essay about all the ridiculously complex challenges like fitting letters / paragraphs to pages, or splitting those that won't fit to the next page, and how you also have to split tables, and restrict image sizes etc, and how browsers themselves pretty much don't have ANY apis that you can use to do certain things, so we had to literally invent our own hacky ways to achieve a bunch of things.

But I'm happy to say that we did it. it works.

13fec56 brings paper-mode along with a ton of other features! You can read about it all here.

And perhaps I'll still go ahead and write that 100 page long essay using Cryptee Docs now! hahah

Give it a try, let me know what you think, and please shoot bugs you might run into our way. We made sure things render accurately even across different browsers / systems and even on devices with different font-renderers. But we also know on things like Firefox for android, lines on underlined text / strikeout text etc may occasionally be a pixel or two off compared to Safari on Mac for example, and if you've got enough of them (say 100 lines of underlined text, could potentially cause a 100px shift in the way your document is rendered across devices)

The export should be accurate, but rendering may not be. Lots to test, lots to experiment! But figured we gotta start somewhere!

Thanks a million for opening this, and for your patience as we literally had to invent a bunch of new ways to accomplish this all in-browser!

Best,
J