-
-
Notifications
You must be signed in to change notification settings - Fork 121
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
Add first line indent to HTML #1858
Comments
I couldn't find a way to assign you to this issue, @zxygentoo, so I'll tag you instead. I've made some improvements to the first line indent feature for ODT, and moved the settings to the Format tab. See #1857. It should make it straightforward for you to add it to HTML as well. |
Cool, I will take a look. |
Th gist of it is that there are now three new private/protected variables in the self._firstIndent = False # Enable first line indent
self._firstWidth = 1.40 # First line indent in units of em
self._indentFirst = False # Indent first paragraph I hope they are self-explanatory. The default value for the indent width is the value that Libre Office defaults to, The |
Running more tests while reading some of the code, two questions:
In my tests, Calibre seems produce better formatted ePub, Pandoc often remove HTML element classes hence lose styling due to its design. |
The |
I'm no Calibre expert, but it seems plausible to make the |
The code seems use different tags for preview and export. Are there reasons beyond better looking preview? If not, maybe we can just use one set of tags for both:
and add these to html class, eg. This seems:
For NW to make exported html with semantically meaningful classes seems sensible and beneficial? Calibre's default regex only match class=chapter, and relying more on textual info. Not that extensible but it's a different problem. And even only with the chapters will make a quite useful ToC most the time. |
There is a very good reason for doing it this way, and it has in part to do with HTML imports and also with ebook compatibility. The preview needs to follow the strict levels in order to generate the correct heading sizes since they cannot be overridden in the view. |
As for Calibre support, I do think tuning the In either case, let's not change these things now. This needs a separate feature and discussion. I also need to refresh my thinking on why it was made this way in the first place. Adding more classes is anyway a good thing to do, and I've been gradually doing so. |
Sure, let's limit the scope of this task. And these basically are just questions from reading the code anyway.
Thought of this after posted the last comment. If we lookout to the future a bit here. From the design perspective, it seems the least surprised path for user is to keep the preview as close as possible to the export (and strive for that export can be converted by Calibre to an eBook sensibly close to the preivew). And it seems the current doc viewer already can't do that anyway (eg. text-indent). So for the long run, what's your thought on this? QWebEngineView is of any use? (My Qt knowledge is basically nothing, so I'm just wild guessing at this point) |
To make my point cleaner, the docbuild preview seems inherently serve different purposes from the view document viewer (the one besides the editor, which works perfectly fine for what it is), and maybe should be treated differently. |
The preview is only intended to preview the text, like header formatting, what is and isn't included, etc. It was never intended to preview the exact result of the saved document. It simply can't. I've pretty much added the formatting that can be added. I don't want to add a full web view either. That is a very bulky thing to include. I think the current solution works well as it is. It won't be any better in Qt6 either as far as I can tell, so it is what it is. |
That said, it is possible to generate the preview line by line with direct paragraph and character formatting instead, without going via HTML. It gives full control of all formatting. It is a lot more work though, and requires a completely new formatting class. It is an option though, and could also be used to improve the document viewer. However, that's a separate task. What would be needed for this is a ToQTextDocument builder class that outputs a QTextDocument. The document can then be added directly to the viewer or build preview panels. It may not be that much slower to build either. This is how I'm generating the document in my other project Collett, which is written in C++, and therefore much faster than novelWriter. |
I've made some major improvements to the Tokenizer in #1885. It now handles all the combining of individual lines belonging to the same paragraph, so the different format classes for Markdown, HTML and ODT no longer has the tricky logic with I will also move the entire preview logic out of the |
I've now merged #1892, so there is no more HTML4 preview stuff in the That means first line indent can now be added here for display in the Manuscript build preview. Not sure if you're moving ahead on the HTML implementation, but if you are, I can handle the preview part of it. |
Caught up between work and moving for a couple weeks. Now as things settled a bit, will get back to this. Haven't read the code carefully yet, but from the comments it seems a great direction. |
Yeah, so the problem is that after me rewriting the Tokenizer class to handle all the paragraph processing there, and also adding text indent there, the code needed to add it to HTML is exactly 2 lines. I just piggybacked it onto #1898. Sorry about that! Feel free to have a look if there is anything more that is needed for this feature though. |
😂 I just want the feature, and this seems way better than if I added it to the old code. Just tested it, works like a charm~ |
Great! I was just worried you had spent time on making it work, and me just reshuffling it all and break everything for you. 😄 |
The first line indent feature should be extended to include HTML, not just ODT. It also needs more settings to be customisable enough to include standard from other languages than English. See PoC PR #1851.
The text was updated successfully, but these errors were encountered: