DOCX Input [Calibre native]

[SauliusP.]

As a first DOCX Input developer, I am starting this thread for a new Kovid's baby: native DOCX Input.

So with big interest I hurried to get dev trunk and, unfortunately, on the first try got the exception:

Spoiler:

InputFormatPlugin: DOCX Input running
on /tmp/calibre_0.9.33_tmp_HdwPid/qemoxw.docx
Traceback (most recent call last):
File "site.py", line 58, in main
File "/Advanced/workspace/Calibre/src/calibre/utils/ipc/worker.py", line 189, in main
result = func(*args, **kwargs)
File "/Advanced/workspace/Calibre/src/calibre/gui2/convert/gui_conversion.py", line 31, in gui_convert_override
override_input_metadata=True)
File "/Advanced/workspace/Calibre/src/calibre/gui2/convert/gui_conversion.py", line 25, in gui_convert
plumber.run()
File "/Advanced/workspace/Calibre/src/calibre/ebooks/conversion/plumber.py", line 1010, in run
accelerators, tdir)
File "/Advanced/workspace/Calibre/src/calibre/customize/conversion.py", line 239, in __call__
log, accelerators)
File "/Advanced/workspace/Calibre/src/calibre/ebooks/conversion/plugins/docx_input.py", line 21, in convert
return Convert(stream, log=log)()
File "/Advanced/workspace/Calibre/src/calibre/ebooks/docx/to_html.py", line 85, in __call__
self.read_page_properties(doc)
File "/Advanced/workspace/Calibre/src/calibre/ebooks/docx/to_html.py", line 164, in read_page_properties
for p in descendants(doc, 'w', 'w:tbl'):
File "/Advanced/workspace/Calibre/src/calibre/ebooks/docx/names.py", line 105, in descendants
return elem.iterdescendants(*map(expand, args))
File "lxml.etree.pyx", line 1290, in lxml.etree._Element.iterdescendants (src/lxml/lxml.etree.c:40339)
TypeError: iterdescendants() takes at most 1 positional argument (2 given)

[kovidgoyal]

That's caused by the version of lxml being too old in the calibre OS X build, it will be updated when the next calibre release is made. In the meantime if you want to workaround it, you can replace the line

descendants(doc, 'w:p', 'w:tbl')

with
XPath('descendant::w:p|descendant::w:tbl')(doc)

there may be other places where you will need to make the change as well.

[kovidgoyal]

I just pushed a commit that should make it work even with older lxml, I haven't tested it, however.

[SauliusP.]

Updated, working. However, what about font embedding? I saw some code regarding fonts, but how is it intended to work? I was doing font scanning and caching, what approach is taken with native plugin?

At least for me fonts are not embedded in the resulting epub/azw3.

Update: OS is 64bit Ubuntu Precise.

[kovidgoyal]

Font embedding works fine for me. Look for the @font-face rules that define the embedded fonts.

[SauliusP.]

Cannot find any in stylesheets.

[SauliusP.]

Might this in the console be related:

'embed_font_family': None,


If so, where to set this to "True" or something like that?

[kovidgoyal]

That has nothing to do with it, it comes from a later stage in the conversion pipeline, the docs input plugin embeds fonts right at the beginning.

Post a docx file for which you fail to get embedded fonts.

[SauliusP.]

Originally Posted by kovidgoyal

Post a docx file for which you fail to get embedded fonts.

I didn't get fonts embedded on 20 docx files, so, I believe, it is not file related, but here you go, one I've used for demo features.

[kovidgoyal]

That docx file has no embedded fonts in it. If you want the fonts to be embedded you need to tell Word to do that explicitly in the Word options.

In other words, only if a font is embedded in the input document will it be embedded in the output document.

[SauliusP.]

Any plans to embed external fonts, that are simply used in the document?

[kovidgoyal]

I dont mind adding an option to do that, but it belongs in the main conversion pipeline not in the docx input plugin. I'll get to it when I have time, or you are welcome to submit a patch for it.

[SauliusP.]

Allright. I simply think, that at least because of docx nature, it is unconvenient for users to embed fonts into docx—it is a "draft" of the book, not the book itself. Also, embedding option is global to Word, not to the file, which is also inconvenient.

I'll consider the patch, however. Wonder if font scanning and caching would be a good option for that? Also might be an idea to enable font scanning on Calibre's startup. Otherwise it would be a performance overhead to search for system fonts on every conversion, if several takes place.

[kovidgoyal]

calibre already does cached font scanning. Thats how the embed font family option (among many other font processing tasks in calibre) works. If you want to work on the patch, look at how the embed font family option is implemented first.

Also, I dont see why emebedding fonts in a draft in progress makes any difference, it's not like it significantly changes save time for the docx.

[SauliusP.]

I'm from an old school, where each kilobyte was valuable :-D So embedding, say, Verdana font in every DOCX I have (>1000), when it is installed in the system, seems like overhead and space waste for me :-)

Also, if I have some docx book, now I need to open it in Word with enabled "embed fonts" feature (which is usually turned off for most of the people), save it and only convert then.

No no, not convenient!