crowdagger / crowbook Goto Github PK

Not really an issue, but more a lot of issues with the ODT output, which has totally fallen behind and I am not able to maintain. I am thinking of dropping it for the time being, particularly since copy/pasting HTML output into LibreOffice probably gives some better result. But am open to some feedback, is anybody actually using this feature?

Currently I'm trying to compile Rustbook into PDF natively with crowbook.
Building PDF with rendering.inline_toc: true generates incorrect document:

pt1.md

# Chapter A
text
## Section A1
text

pt2.md

## Section A2
text

included as:

+ pt1.md
-- pt2.md

produces incorrect TOC entry for Section A2 (1.2.............. instead of 1.2....Section A2).
It may be caused by difference in LaTeX code:

% skipped
\section{Section A1}
% skipped
\end{mdcodeblock}\section{}
\label{chapter-2}
\subsection{Section A2}
% skipped

Otherwise when pt1.md and pt2.md are concatenated into one file (as simple as cat pt1.md pt2.md > chapter.md), TOC looks like it should do.

If you need some more examples to reproduce, I may upload them as a gist or a repo.

Add an option to the latex template, to generate stdpages with fixed size typewriter font and 60 lines per page and extra wide annotation border. This is the standard for sending drafts to lectors (at least in germany).

There's a latex package here which is overriding all styles by just including something like this in the header:

\usepackage[hyphen=false,parskip]{stdpage}

I think it can be easily included as option for the latex template, I can send you a PR, if you think this is good feature?

Currently, doing e.g.

crowbook -s file.md --to html might print HTML to stdout... or to a file if file.md includes a yaml block with output.html. This is annoying as that prevents crowbook from being runned from emacs with markdown mode.

Currently, Epub generation is done using the zip command, which is a portability problem (on Unix systems it is probably installed, but not necessarily on Windows). It would be better to use a library such as zlib-rs (https://github.com/alexcrichton/libz-sys) or https://crates.io/crates/flate2.

Currently, detecting repetition with caribon is a bit of a hack since it edit the resulting HTML document; it would be better to manipulate the AST directly, so it can work better with languagetool support.

Except for local images, which get copied to the EPUB files, it is not possible to embed additional files (e.g., fonts) to the final EPUB. This feature would probably make sense for the yet-to-come "render HTML in multiple files in a directory" renderer (and probably not for standalone HTML or for PDF).

output: [html.dir]

will generate an enpty "output_html" directory and an "auto" directory containing the actual output.

When rendering my book, I get the following output:

Info: Succesfully generated EPUB: working_9_to_FOSS.epub
Error: Error rendering pdf: Error during temporary files editing: could not open file in tmp directory: 'result.pdf'

After that I find an EPUB and a PDF file in my working directory but the PDF file is empty.

I'm on maxOS Sierra.

As of version 0.0.9, pulldown-cmark supports alignment in tables, but it is currently not used by crowbook in any renderer (actually the information is already lost in the AST)

As I use markdown first to publish my texts using Jekyll, my markdown files are builds the Jekyll way. So they have a YALM header. At least, I expect Crowbook to ignore them, so I would not have to manage two versions of each text. But this is not the case, and the result is ugly.

Suggestion: it should be even better if the YAML header could be use by crowbook instead of an external configuration file. Maybe a YAML key named crowbook should be use to avoid conflict of key naming between Jekyll and Crowbook. So the file header should look like:

---
layout: post
title:  Disparition
date: 2016-01-18 00:30:05
categories: blog
type: nouvelle
crowbook:
  title: Disparition
  author: Stéphane Mourey
  lang: fr

---
And now, for your pleasure, a brand new history....

Suggestion 2: there should be some redundant keys, like the title one in my sample. So, may crowbook read the whole YAML to get them, instead of repeating them in the file. I don't know, just thinking.

Currently, the only HTML renderer (besides EPUB, which is technically HTML too) generates a standalone file. For long texts, it might make more sense to give the possibillity to generate a multiple file, probably in a directory with one file by chapter. This could be an additonal option output.html_dir that would operate in a similar manner to the EPUB renderer: generate one file by chapter in this directory, generate a CSS files and copy linked images in this directory.

Currently the top level headers are chapters. But sometimes chapters are separated into multiple "parts" (or "books" or "episodes" or whatever). It could be nice to have an option for this.

I was thinking maybe a directive in the chapter lists, eg instead of

+ chapter_1.md
+ chapter_2.md
+ chapter_3.md

+@ The first part (numbered)
+ chapter_1.md
+ ...
-@ Unumbered part
+ chapter_n.md
...

But it's a bit ugly. Plus I'm not sure exactly of the various usages (a part should probably generate a page on its own, but is it enough to have a name, as for chapter's titles, or should it also have a way to include arbitrary markdown?)

Links containing dashes don't appear correctly in PDF output. It is probably because characters are escaped when they shouldn't be.

Long lines should wrap or something like that, not render like this:

It would be nice to have a way to have superscript and subscript syntax. The pandoc extension could be a source of inspiration.

Superscripts are the priority, as they might be used in literary texts (e.g. "1^er^").

It could make sense to move the parser part to a different crate (e.g. crowbook-parser).

Pros:

• would make the code more reusable (since it is build on pulldown-cmark, might not make most sense, but the enum-based parser might be easier to use by some people?)
• some additional feature (e.g. superscript) can require modification of parser code, it would break compatibility, which block for a 1.0 release (with this crowbook could be 1.0 even if crowbook-parser is still 0.x)

Cons:

• might not be that obvious to do ;
• is there really a need to that much crowbook-xxx libraries?

This is because it tries to create a temporary directory first before coyping the files. Maybe this feature is legit to prevent, but at least crowbook should not panic.

Currently, I am unable to build binaries for other targets than Linux. In the past, I used trust to build and deploy binaries using Travis and Appveyor but I have been unable/incompetent to do it for the past few releases.

So if someone understands these platforms better than me (that's not hard ^^) and has any idea how to fix the appveyor.yml/.travis.yml files and/or what I need to do on these sites I'd be more than happy :)

Logs on travis (it doesn't even build there anymore because of syntect?) : https://travis-ci.org/lise-henry/crowbook
Logs on appveyor: https://ci.appveyor.com/project/lise-henry/crowbook (here it builds correctly but i am incapable of deploying: https://ci.appveyor.com/project/lise-henry/crowbook/deployment/2575742)

I just download the v0.14 .deb file for 64bits system and dpkg -i on it.
Then I tried to create a single markdown page and all I got is this error :

$ crowbook --lang en -s text.md
CROWBOOK 0.14.0
X text.md: Could not find file 'text.md' for book chapter
ERROR text.md: Could not find file 'text.md' for book chapter

Just ran crowbook on a Windows PC where the zip command is not present. Unsurprisingly, generating an EPUB file fails (though the error could be clearer). Suprisingly, though, an empty EPUB file is still created.

When adding:

\usepackage[
  usenames,
  dvipsnames,
  svgnames
]{xcolor}

to the template.tex and changing the appearance of inline code in md to:

- \newcommand\mdcode[1]{\texttt{#1}}
+ \newcommand\mdcode[1]{\texttt{\color{Red!33!Black} #1}}

Bookmarks are messed up as follows:

when using a header in your markdown source like:

...

## Restricted `begin_edit()` and `end_edit()`

...

XeTeX    : 3.14159265-2.6-0.999991 (TeX Live 2019)
crowbook : v0.15.0
OS       : macOS Catalina 10.15.2 (19C57)
hardware : MBP 15" 2018, i9 2.9GHz, 32GB, 1TB, Radeon Pro 560X

Finally got a chance to test crowbook on Windows, and there are some issues:

• mingw builds run fine, but msvc ones require vcruntime140.dll
• LANG environment variable not found: should only be printed on verbpse (or not at all)
• colour characters should not be output if term dosn't support it
• also, zip or latex commands not found should have clearer message.

It displays things quite... weirdly when html_single.one_chapter is true and there are footnotes in the chapters.

A recent commit changed the way images included in Markdown files are rendered: they are now displayed at 80% of the width of their block. It is a bit better than the previous state, which simply included images at their resolution, making high-resolution pictures not even display entirely.

Things could be handled better, though. An idea would be to distinguish between pictures that are included on their own paragraph (which probably benefit of being included full width) and the ones that are inlined in a paragraph, (which probably don't):

Here is a picture that probably should be more or less full width:

![Alt text](picture.png)

While this one ![happy emoticon](emoticon.png) probably shouldn't :)

Easier said than done with the current way the parser is written, though...

Inline toc (if rendering.inline_toc is set to true) is not displayed in EPUB rendering.

Also, it doesn't behave well with standalone html rendered when html_single.one_chapter is set to true.

I was thinking about what I should need to make the HTML output of Crowbook to remember the last vertical position when the user leaves the page and restore it when he comes back, even if the window has another size. It can be done purely with JavaScript, but there a part that would be better done when Crowbook output the HTML, and that's my request.

I would like you to add a unique id to each paragraph. Numbering is not required, but it should be easier for you. I suggest something like cXXpYY where XX is the chapter number, and YY the paragraph number.
So we'll have something like:

<p id="c1p1">blabla</p>
<p id="c1p2">blabla</p>
<p id="c1p3">and so on...</p>

Currently, I do not know when I will have enough time to write the JavaScript part, so I made this request first, in the hope to make this feature implementation progress faster.

Page numbers are offset in TOC by -10.

Image 1 (click to reveal)

Image 2 (click to reveal)

Side note: Although the images here show the use of a custom LaTeX template, I can reproduce this with the LaTeX template shipping with crowbook.

XeTeX    : 3.14159265-2.6-0.999991 (TeX Live 2019)
crowbook : v0.15.0
OS       : macOS Catalina 10.15.2 (19C57)
hardware : MBP 15" 2018, i9 2.9GHz, 32GB, 1TB, Radeon Pro 560X

When I try to open the rendered ePub in iBooks, it rejects it because:

Line 116: attributes construct error
Line 116: Couldn't find end of Start Tag reference

and when I run the same book through epubcheck, I get this:

Validating using EPUB version 2.0.1 rules. FATAL(RSC-016): deathworlders.epub/OEBPS/content.opf(116,50): Fatal Error while parsing file 'Element type "reference" must be followed by either attribute specifications, ">" or "/>".'. ERROR(RSC-005): deathworlders.epub/OEBPS/content.opf(-1,-1): Error while parsing file 'Element type "reference" must be followed by either attribute specifications, ">" or "/>".'. ERROR(OPF-031): deathworlders.epub/OEBPS/content.opf(114,72): File listed in reference element in guide was not declared in OPF manifest: OEBPS/nav.xhtml. ERROR(OPF-031): deathworlders.epub/OEBPS/content.opf(115,80): File listed in reference element in guide was not declared in OPF manifest: OEBPS/title_page.xhtml. ERROR(RSC-008): deathworlders.epub/OEBPS/content.opf(114,72): Referenced resource is not declared in the OPF manifest. ERROR(RSC-008): deathworlders.epub/OEBPS/content.opf(115,80): Referenced resource is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_000.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_001.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_002.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_003.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_004.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_005.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_006.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_007.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_008.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_009.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_010.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_011.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_012.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_013.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_014.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_015.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_016.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_017.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_018.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_019.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_020.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_021.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_022.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_023.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_024.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_025.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_026.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_027.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_028.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_029.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_030.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_031.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_032.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_033.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_034.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_035.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_036.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_037.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_038.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_039.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_040.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_041.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_042.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_043.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/chapter_044.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/nav.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/stylesheet.css' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/title_page.xhtml' exists in the EPUB, but is not declared in the OPF manifest. WARNING(OPF-003): deathworlders.epub/deathworlders.epub(-1,-1): Item 'OEBPS/toc.ncx' exists in the EPUB, but is not declared in the OPF manifest.

When you use only on sharp to define the chapter title, it is not recognized by Crowbook.

The markdown specifications said that:

#My Title

is equivalent to:

My Title
========

but Crowbook does not treat them the same way... and simply do not see any title when using the sharp version.

Currently, Crowbook can panic when compiling a template. It would be nice to see if there is a function in mustache library that returns a Result instead, or, alternatively, to use this new feature in Rust to transform panic into an error.

Sometimes, depending on where you run Crowbook from, the printed paths for the documents that can be generated can be unnecessarily verbose, e.g. some_dir/../output/foo.pdf instead of output/foo.pdf. A previous attempt to fix this was done using std::fs::canonicalize, but it caused issues as this function will return an error if the file doesn't already exist.

Error messages provided by crowbook should be improved. E.g., currently it is

"error: File not found: cahpitre_05.md"

A more useful message would be e.g.:

error in foo.book at line 42:
File not found: cahpitre_05.md"

It would be nice to have an option that could convert some chains of characters into special characters, in a way similar to what latex does.

E.g.:

• << -> «
• >> -> »
• -- -> –
• --- -> —

LaTeX template should probably be fixed.

There's still an issue when built without nightly feature and called with -Sv flags.

Steps to repeat

$ rustc -V
rustc 1.29.0 (aa3ca1994 2018-09-11)
$ cargo new cooktest
$ cd cooktest
$ vim Cargo.toml
....

append

[dependencies]
crowbook = {version = "0.11", default-features = false}

Then build

$ cargo build

Eventually I get:

   Compiling crowbook v0.11.4
error[E0432]: unresolved import `text_view`
  --> /home/paul/.cargo/registry/src/github.com-1ecc6299db9ec823/crowbook-0.11.4/src/lib/html_dir.rs:28:5
   |
28 | use text_view::view_as_text;
   |     ^^^^^^^^^ Maybe a missing `extern crate text_view;`?

error[E0432]: unresolved import `text_view`
  --> /home/paul/.cargo/registry/src/github.com-1ecc6299db9ec823/crowbook-0.11.4/src/lib/book.rs:37:5
   |
37 | use text_view::view_as_text;
   |     ^^^^^^^^^ Maybe a missing `extern crate text_view;`?

error[E0432]: unresolved import `text_view`
  --> /home/paul/.cargo/registry/src/github.com-1ecc6299db9ec823/crowbook-0.11.4/src/lib/epub.rs:29:5
   |
29 | use text_view::view_as_text;
   |     ^^^^^^^^^ Maybe a missing `extern crate text_view;`?

error: aborting due to 3 previous errors

For more information about this error, try `rustc --explain E0432`.
error: Could not compile `crowbook`.

To learn more, run the command again with --verbose.

I don't think verbose provides any further useful information other than the rust command used to compile. I can add if you think it's worth it.

Maybe it would make sense to change the header style in the latex output to:

% Redefine headers
\pagestyle{fancy}
\renewcommand{\chaptermark}[1]{\markboth{\sffamily\normalsize\bfseries\thechapter.\ #1}{}}
\renewcommand{\sectionmark}[1]{\markright{\sffamily\normalsize\thesection\ #1}{}}
\fancyhf{}
\fancyhead[LE,RO]{\sffamily\normalsize\thepage}
\fancyhead[LO]{\rightmark}
\fancyhead[RE]{\leftmark}
\renewcommand{\headrulewidth}{0.5pt}
\addtolength{\headheight}{2.5pt}
\renewcommand{\footrulewidth}{0pt}
\fancyfoot{}

looks like this:

E.g. if a file contains the image foo.png, it works fine if it is the actual image, but not if it is a symbolic link to bar.png.

Fantastic project! I'm working on converting a book that we had previously written in InDesign back to markdown, and it looks like the default PDF formatting is resulting in incorrect layout:

Here's the example paragraph in the screenshot if you want to test this:

A good way to think about the difference between this method and `didUpdateComponent` is that `didMount` is an opportunity for configuration of the **view**, while `didUpdateComponent` and `initWithComponent:` is about configuring the **controller itself**. The one major exception is that `initWithComponent:` is called on a background thread, so it’s common to wait for the first mounting to complete configuration that had to be done on the main thread. This is something we’d like to fix.

Currently, it is possible to fully replace a template, e.g. with

epub.css : my_style.css

It would be nice, though, to have a way to just add a few lines of code before/after default templates, e.g.:

epub.css.append: "h1 { colour: red; }`

Is possible to have an output file with the txt format?
My concern is to be able to use the application for wiki text like wikipedia or https://doc.ubuntu-fr.org

Hey,

currently I'm using crowbook for compiling output for my novel and Ghostwriter for editing. It's a beautiful, well featured distraction-free markdown editor, but it's export and project capabilities are limited. It just uses pandoc on the current document.

The idea is, to have a kind of Markdown IDE. It would be nice to integrate multifile project support. Perhaps by loading a .book file. Then the structure of the book would be displayed, also over multiple documents. A nice dialog for crowbook settings would also be nice.

Ghostwriter is written in C++ and Qt, so it would be relatively easy to integrate crowbook as a library. I know it's a lot of work and the Ghostwriter author is very busy. But the project is still alive and well developed.

What do you think on that idea? Are you perhaps willing to participate?

I may use crowbook to format some short stories, with only one md file, so it should be great to have a option to change the output to something adapted : there is only one chapter, one title for both the book and the chapter, no numbering and no blank page to start with.

I know that the support of ODT is currently experimental and I do not expect you to fix it quickly (and I do not need it to be fixed), but as I saw the bug, I think it's better to report it so you can keep a track of it and decide when and what to do.

So, here we go: when the lang option is set to fr, when the output is opened in OpenOffice, OO seems convicted that the text is in English, and so nearly every single word seems incorrect to its eyes.

Currently, the toc.ncx file of the EPUB only displays chapters. This is a problem because even with EPUB3 it seems to be what most readers use to display the TOC. The main problem is that the ncx format is quite different from the <ol>/<ul> format that is used in other places, and particularly I am not sure how a toc like

Subsection 0.0.1
Chapter 1

should be rendered, given that a <navPoint> must have a <navLabel> and a <content>. If I am not mistaken, the only solution would be to make the first subsection appears on the same level as a chapter, which doesn't seem quite right.

Code syntax highlighting breaks for me after comments. This is reproducible with other languages.

Using the latest binary from the releases for mac, crowbook-v0.14.0-x86_64-apple-darwin.

Let's say you have the following structure:

• common.book
• images/
  • foo.png
• 01/
  • 01.book
• 02/
  • 02.book

In common.book, you want to define the base path for images to images/:

resources.base_path.images: images/

You also want to specify an icon for html rendering:

html.icon: foo.png

But now, when you run crowbook 01/01.book you get an error: "Could not find file '01/../images/../foo.png'"

This is because "../" is concatenated to html.icon, which would be the thing to do if resources.base_bath was not defined, but in this case it causes a problem.

I just get this problem with images, but I suspect this will occur with all others files.
First, let me show you the directory structures of jekyll. Most of the MD files are stored in the directory _posts and that's main content of the website. Inside those files, relative URL are supposed to be relative to the top of the website. Images are usually stored elsewhere, as the _posts directory will not be published as it is. So let's say that images are stored in the img directory. So, we have this structure:

/
  _posts/
     my-first-short-story.md
     my-second-short-story.md
  img/
    beautiful.png
    ugly.png

So, in my-first-short-story.md, I have a image linked in markdown this way:
![Ugly...](img/ugly.png)
No problem for Jekyll. But Crowbook is not able to find the file when converting my-first-short-story.md.
I suspect this to affect any relative URL.

A solution may be to add an option to set the root to start with when using relative url, something like the base href directive in HTML.

Hi,

I wanted to render an EPUB of trpl2 with colored cargo output like this:

I made a simple edit to syntax.rs to achieve this:

// Add custom syntaxes
let mut ss = syntect::parsing::SyntaxSet::new();
ss.load_syntaxes("/path/to/custom/syntaxes/", true).unwrap();
ss.link_syntaxes();

// Add custom theme
let theme_name = String::from("/path/to/custom_theme.tmTheme");
let theme_path = Path::new(&theme_name);
let theme = syntect::highlighting::ThemeSet::get_theme(theme_path).unwrap();

However I think it would be good to be able to set this via the configuration file. I can prepare a PR with these changes if you think this would be beneficial.