[Plugin] DOCXImport

[DiapDealer]

Originally Posted by explorabeth

Does this plug in save a copy of all jpegs and a folder in the local temp folder?
I've had a great semester using this so far, but now i have 300,000 jpegs in my temp folder.

No. Not that I know of. Not unless something crashes, anyway. The temp folders that are created to build the epub are automatically deleted after a successful plugin run. It certainly doesn't store any files in the root of the Temp folder.

I just verified that the temp folder this plugin creates gets deleted on my machines after a successful run.

Sigil itself will also leave a temp folder behind if there's a crash. But if you're not experiencing any crashes, then Sigil (and this plugin) should definitely be cleaning up their own temp folders after successful runs.

I can't vouch for all Sigil plugins, though. Temp folders that plugin devs create manually with their plugins won't clean themselves up. They have to make sure to clean up before returning control to Sigil. Perhaps you use other image-related plugins that are leaving strays behind?

[DiapDealer]

Released version 0.2.4. Please let me know if I broke anything in the process.

• Update mammoth/cobble modules to latest upstream
• Tweak mammoth to create a "title" attribute for images if the title property is defined in the docx
• Remove extraneous parsimonious module

[BetterRed]

Originally Posted by DiapDealer

• Remove extraneous parsimonious module

Meany. BTW it just worked fine on 7 Docxies

BR

[DiapDealer]

Originally Posted by BetterRed

Meany. BTW it just worked fine on 7 Docxies

BR

For the life of me, I can't figure out why I'd included it in the first place! I could have sworn one of the other modules was dependent on it when I first created the plugin, but nothing needs it now. I'm beginning to suspect nothing ever did--in this plugin, anyway. I'm sure Parsimonious is a wonderful module in its own right, though.

Thanks for testing the plugin and getting back.

[gingerbeardman]

Originally Posted by DiapDealer

One thing I might be willing to do is to have the plugin (after the conversion is complete) automatically insert Sigil split markers in front of tags with certain user designatable attributes (hx tags of class "xxx" or just hx for that matter). Would that be useful to anyone?

This would be really useful. I have 40 docx (one per short story) and each is split into pages as you might expect. I need to find a sane way of processing them all.

[patrik]

Hmm, I have used this excellent plugin every now and then for some years (it's my favorit when converting docx to epub, albeit I haven't done many). It has always worked but now I tried to import a docx I just got from a friend.

I have searched but not found anything about this.


TypeError: _read_image() missing 1 required positional argument: 'title_text'
Error: _read_image() missing 1 required positional argument: 'title_text'

(I'm using libreoffice in case there is a difference if editing is needed. I do believe the docx itself was created by word.)

[DiapDealer]

If it was a Word docx document that you converted to LibreOffice docx, there may be some discrepancies. Try saving the docx (after backing it up of course) as a LibreOffice docx document -- meaning don't try to preserve the Word formatting. Also look at the properties of all images in the document. Make sure the title_text attribute is filled.

I'll look into seeing how that attribute gets filled across the different WP applications and see if there's a way to avoid the error when it's missing.

Looks like it probably has something to do with the changes to the last version of the plugin (v0.2.4). If that's the case, you could always try v0.2.3 and see if the issue goes away. That would actually help me narrow it down.

[patrik]

I have tried with the original document (which I'm guessing was created with Word) and just opening it and re-saving it (as docx) from libreoffice. No difference.

Not sure how to find and enter a value for "title_text". I can't find anything with that name in libreoffice.

Checking properties for all images, all had an entry for "Name" (which I would guess it the title?). All had empty fields for "Alternative (text only)". I entered values for all those , no difference.

(I could add it to Calibre and convert to epub, if that gives any information?)

When saving it as an odt-file, I could use the plugin ODTImport and import it.)

Thanks,

[DiapDealer]

Did you try v0.2.3 of the plugin to see if it made a difference. I may have added that to my post after you'd seen it.

[patrik]

Yes, with 0.2.3 it worked! (I was using 0.2.4.)

[DiapDealer]

Thanks for checking. That will give me a great idea of where to start looking to fix the v0.2.4 version!

[patrik]

Please let me know if you want me to test anything.

Thanks.

[patrik]

Hmm, I noticed several of the images in the docx file was not transfered to the epub, some was.

[DiapDealer]

Yeah, I can tell by the errors/code that something is rare-ish about some of the pictures in your docx. I think some of them must be stored as binary image data or something.

Can you get me a copy of the document without violating copyright? Even if you have to strip out the text and leave some of the problematic images, it would probably be helpful.

Just make sure you don't post copyrighted material to MobileRead, please.

[DiapDealer]

Mammoth doesn't officially support the conversion of WMF/EMF graphics in docx documents. The images that are being skipped when using this plugin are, in fact, EMF graphics. So there will likely be no "fix" for this (though I will fix the error received in v0.2.4).

There's some code that might be able to be used to convert the EMF graphics to something usable, but it would never work on all of the supported platforms. So I probably won't pursue it.

I'll add a notice to the first post concerning the unsuitability of WMF/EMF graphics for use with this plugin.