Manuscript Export #622
Comments
|
This. I believe (apart from actual writing support features) that a manuscript formatting tool would be a sane must-have in a writing tool(kit). Equally, it'd be nice to be able to export to ePub. 😄 |
|
This is already partially implemented with the new Open Document exporter I added in release 1.2. There are options in the Build Tool that lets you produce a decent manuscript export. Depending on the publisher's standard, it may have to be tweaked a bit. I plan to add a few more options when I redesign the Build Tool, but unless there are specific requests it won't be radically different. As for ePub and other tools aimed at self-publishing, I have thought about it. The thing is there are already good tools for generating such formats, and novelWriter is only intended to build a manuscript. I may add an ePub export format, but it really isn't high priority right now. There's a ton of writing support features to implement. The HTML output can be tweaked to be friendly to ebook converter tools like the one in Calibre, so there is a path. If there are improvements that need to be made to the HTML export to better support the Calibre converter, I'm happy to make those happen. |
|
The most direct and impactful change you can introduce to allow .htm export to be EPUB-friendly is to do away with the Calibre by default honors fixed width properties and all |
|
Yes, I plan to extend the HTML options as well. Particularly the bits needed for HTML to EPUB conversion via Calibre. The new build tool will have a completely new way to set build options, which will allow for a lot more features. It will also allow the user to save multiple build presets. I'm already working on the underlying mechanics for this. Any ideas for useful build options are welcome. |
|
Similar to #948. LibreOffice has style names for some other (not all) formatting options of novelWriter. I'm currently unsure of the situation in OpenOffice and MS Word. So, like a normal paragraph is called "Text_20_body", the following are available as standard styles in LibreOffice:
It would be nice for a way to "talk" to these elements all at once, without having to seek out every instance of them in the text (in order to, for example, change the size of the indent). Unaccounted for are centered text, left align, right align, indent right. Unaccounted for character styles are nested italics+bold, and strikethrough. I'm wondering if the What I'd also find useful is a custom style for the A different style for paragraphs that follow any kind of headline, in order to be able to set them to "no first line indent". Alternatively, because LibreOffice has a separate style for indented paragraphs, let the user select that as default (its name is "First_20_line_20_indent") and "Text_20_body" as special paragraph styles after headlines. Option to write the manuscript title and author into their respective property fields so they can be used in placeholder headers. This seems to be a lot, but ideally(?) novelWriter should output a ready I find it somewhat important that novelWriter doesn't come with "opinions" on its own. For example, currently a left-indented paragraph has a set indent of 1.41cm (probably because there wasn't any other way to do it), and an Smol thing that is probably changed in the new version anyway: As is known, I'm on a tiny screen, and the build window, when including the GUI window title bar, is vertically a little too high. The bottom row of buttons is cut off a little. This needn't be, because there is no reason why this window shouldn't be allowed to be dragged smaller vertically anyway as there already is a scrollbar for the options. Issue I can't give any more information right now: I wanted to use AbiWord (comes preinstalled with Lubuntu 18.04), but it would crash when I tried to open I'm super excited for how the new build and export tool will turn out |
The indent feature is covered by #906 and implementation ideas should be discussed there so they are in the same place.
Those are generated as needed in the same way LibreOffice does it when you modify the alignment of a paragraph. I think the reference to the parent style is preserved, but I can do some testing on this.
All in-line styles are generated on the fly in the same way LibreOffice does it. I used it as a reference for all of this.
It adds custom private styles on the fly, like LibreOffice for this as well. In the odt source they are named sequentially as P1, P2, P3 etc. I didn't use any third party packages for the odt export feature. I tested a bunch and decided against it. I wrote the odt code from scratch myself. I can of course implement more default styles. That's just a matter of adding them to the setup function that generates the ones I needed from LibreOffice defaults. The build code will check against previously used paragraph styles to see if there is a matching one already for each paragraph it sees, so it should automatically pick up any pre-defined styles instead of generating a new one.
Sure, that sounds like a useful addition.
Not sure I understand what you mean.
The odt builder class can take custom settings for all size values, and these will be exposed in the new build tool.
Each text editor seems to have its own little quirks, and deviations from the standard. LibreOffice doesn't follow the Open Document standard to the letter either, which I noticed when I wrote the odt builder. I used the standard as the reference, and primarily used LibreOffice for testing. I also tested with Google Docs, and I think I've also tested with MS Word. If there is no error output from AbiWord, it's hard to say what's happening and what to fix. I can certainly test it.
Cool! I've started slowly working on it, but January has been a bit crazy. I will upload snapshots to the novelwriter-pre repo on Launchpad as soon as there are any changes in main that introduces usable new features. It's always good to have someone try them so that issues can be resolved early. |
I was familiar with the issue, but missed that it also talked about "no first line indent after headline". I've got nothing further to discuss :)
I noticed the P1, P2 etc custom styles when I exported the odt file in LibreOffice to html to glance at the style names. Those would already solve the suggestion I have, but I see no option to access them (i.e. style all instances of P1 at once) within LibreOffice like I would access for example the headline styles or the Text_20_body. The way you phrased it makes me suspect user error on my part. The styles P1, P2 etc are nowhere in my list of styles, not in the custom styles, not in the applied styles where they really should make an appearance. Where are these styles?
Me neither. LibreOffice has the option to insert a "field", like, "page number" is a field. In the document, they would appear with a gray background. Think variables. The .odt build tool apparently leaves them empty for title and author. |
You can just export to fodt (Flat open document), which is a single xml file with an .fodt file extension. You can inspect it in gedit or something, but double-click will likely launch it in LibreOffice or similar. In the flat file you'll see how the formats are built and defined. It's basically how I figured out what exactly LibreOffice does. A HTML export will degrade this information, although it does preserve some of it.
That's what I meant by "private". They are not accessible. I can't remember if I figured out how they are private as opposed to visible. It could be that they don't have a display name. Below are the relevant code bits. I can easily add more default styles, as they are just pre-generated as opposed to auto-generated. But as I said, I can't remember what the criteria are for their inclusion in the LibreOffice GUI. Some of them are certainly "magical" in that LibreOffice checks them against a set of expected styles, which is briefly mentioned in #948 IIRC. The default styles are generated here: novelWriter/novelwriter/core/toodt.py Lines 733 to 805 in 8273fcc The custom P{n} styles are created here: novelWriter/novelwriter/core/toodt.py Lines 655 to 674 in 8273fcc The paragraph style sets are handled by this class: novelWriter/novelwriter/core/toodt.py Lines 997 to 1208 in 8273fcc
Ah, I see. That may be LibreOffice specific stuff. There is a settings section in the document standard that can hold lots of values which aren't necessarily universal. But this could also be ODT standard meta data or even Dublin core. I'll look into it. |
|
I had to check. The title is indeed Dublin core, so I can definitely fix that. The author is trickier, since it actually relies on your personal user data set in LibreOffice, which goes into the Here is what LibreOffice adds to meta data when I open a document from novelWriter in LibreOffice, set the title, and save again: <office:meta>
<meta:creation-date>2023-02-01T14:10:22.242714318</meta:creation-date>
<meta:generator>LibreOffice/7.0.4.2$Linux_X86_64 LibreOffice_project/00$Build-2</meta:generator>
<meta:editing-cycles>2</meta:editing-cycles>
<meta:editing-duration>PT52S</meta:editing-duration>
<dc:title>Sample Project</dc:title>
<meta:initial-creator>Jane Smith</meta:initial-creator>
<dc:date>2023-02-01T14:10:30.182583978</dc:date>
<dc:creator>Veronica Olsen</dc:creator>
</office:meta> |
|
On the AbiWord issue, I see that the novelWriter generated document fails validation on a few points, which I can certainly look into. Maybe AbiWord has crappy error handling. I found https://odfvalidator.org/ for checking this. It generated a few errors on an exported sample project document. |
|
I've fixed a bunch of issues in #1360 for the 2.0.5 release. Mainly updating to ODF 1.3, adding the title and author fields, and making the document pass the official validation tool. AbiWord still won't read it, but since the document is valid ODF, I suspect AbiWord is tailored to read LibreOffice output, and may not be lenient enough to support any valid document. Since it gives no error output, it's hard to debug. |
vkbo
added
next release
|
On the subject of Calibre as an EPUB authoring tool, currently I can't get a generated index to work correctly from a .htm file exported with novelWriter, particularly with a Kobo ereader. The reader jumps to the wrong index, and other features like bookmarks are broken because of it. It may sound quite out of novelWriter's scope and reach, but then I have created other EPUB files with Calibre from other source materials with properly working indexes, and if there is anything novelWriter can do to nudge Calibre in the right direction when converting from .htm, perhaps it is worth looking into it. First I would have to find out what exactly is it that breaks indexes. I am only mentioning it in case someone has run into this same problem, and in case you believe it is worth considering. |
|
I don't consider an EPUB compatible HTML build as out of scope. I intend to address this issue. Feel free to create a new ticket on it if you have done some research on what exactly is needed. I suspect a part of the problem is that novelWriter generates HTML5 rather than HTML4. |
|
Well I can confirm that bare EPUB conversion with Calibre is perfectly compatible with Kobo readers (at least mine). My issue was arising because of a calibre plugin I use especially for uploading to a Kobo reader, which changed the file format. I should report this to the plugin maintainer. Disabling the plugin allowed me to open and use the unmodified .epub file generated by Calibre with successful index use (and other features). You have nothing to worry about on this front! |
|
I've now merged the last bit that is covered by the tasks in the first post. The last changes adds a new Separator style class to the Open Document build, as requested by @HeyMyian, and also adds controls for defining paper size and page margins for the new build tool. This feature ticket has mostly been about the Open Document format. I think any EPUB-related stuff should go into a separate ticket. Since all defined tasks are completed, I'm closing this now. |
The current Build Novel Project tool is flexible and can produce all sorts of outputs. Better support for Open Document and Standard Markdown is in the process of being added. With a proper Open Document export class, it is possible to produce manuscripts that are of the correct formats for submissions.
The standards do vary a bit, so there need to be a few options for tweaking it. The best approach is probably to have a separate tab in the Build Novel Project tool's settings area for manuscript options. This also means that the user can keep their other build settings without having to tune them back and forth between the two modes. Alternatively, there could be an option to have pre-defined and custom build settings in a dropdown list. This way, the user can keep their favourite build settings.
Update
It should be possible to have both. The settings in the Build tools should be split up into tabs. Currently, they are just long enough that having to scroll a few centimetres isn't an issue. But there should be more options for customisation to support manuscript exports, so they should also be available to regular builds. A combination of tabbed settings and saved presets is probably the best solution.
Tasks
The text was updated successfully, but these errors were encountered: