Possible bugs: Editor and converting from docx?

[Quoth]

1) Language
Sometimes there is no language in content.opf. The line

     <dc:language>en</dc:language>

is missing. I thought once it even vanished after I added it. Though some ereaders seem to assume English.
Edit: I converted two epubs to dual mobi. Afterwards the <dc:language>en</dc:language> is gone!

Edit2: Actually it's gone simply re-opening the Editor on the file. What am I doing wrong?

2) Fonts
The behaviour of Embed Fonts is different in the Conversion GUI and in the Editor. The Editor works correctly. Attempting manually or using Check to remove spaces in file names results in fonts that don't work on a Kobo. Leaving the spaces may be OK on a Kobo. Everything is always fine in the viewer. Posts below have the details of the workaround.
https://www.mobileread.com/forums/sh...37#post4108937
https://www.mobileread.com/forums/sh...73&postcount=3

3) Fonts with Font weights that are strange
One font has a 400 setting in the font file. Calibre Embed Fonts in Conversion GUI or Editor, puts font-weight: 5; which isn't recognised by Check. Changing to font-weight: normal; works correctly.
Also some fonts have a string of Panose numbers in the CSS after embedding. Deleting that line in each css seems to be the solution.

Tip: Set Minimum Line Height AND Line Height to Zero (0.0 %) so that the user can use the ereader to set the line height, which should be the default for all ebooks. Different top and bottom margins for each paragraph style are not affected and how you should space in the wordprocessor.

[Quoth]

I think if the Metadata form entry for Language (Calibre Metadata) is blank the Editor removes the <dc:language>en</dc:language> line in content.opf if the default "Update metadata from Calibre" under Calibre integration is checked.

I think this is a bug. Surely the Language in the ebook should initially set the Calibre field and shouldn't be deleted if the box in the form is empty?

Also should it be en or English by default?

Edit: It seems like English in the Calibre Metadata form gives <dc:language>en</dc:language>
in the actual ebook?
Also is Editor -> Help -> Preferences per ebook or for any instance later opened of the Editor? I thought I unchecked "Update metadata from Calibre", but it's currently checked.

[kovidgoyal]

1) If you remove the language from calibre metadata it will be removed from the book when the metadata in the book is updated. That is the desired and correct behavior. And if you want to change editor preferences, the preferences in the last closed instance will win. So close all but one instance and change them there.

2) This is a bug in the Kobo firmware, not calibre. Spaces or indeed any legal characters in a font file name dont prevent them from working or make them incorrect. The is no "correct" filename for a font file.

3) Opena bug report and attach a sample demonstrating the issue.

[Quoth]

Originally Posted by kovidgoyal

1) If you remove the language from calibre metadata it will be removed from the book when the metadata in the book is updated. That is the desired and correct behavior. And if you want to change editor preferences, the preferences in the last closed instance will win. So close all but one instance and change them there.

The problem is that some imported Docx don't set the Language in the Calibre Meta Data. I don't know why.
Generally, yes, the ebook metadata should reflect the Calibre data, but surely the dc:language field should never be completely deleted silently?
I've solved this by making sure the Language is not empty in the Calibre Metadata GUI when I add a docx.

I guess I had more than one instance of the editor open. I do know about last one closes, wins!

Originally Posted by kovidgoyal

2) This is a bug in the Kobo firmware, not calibre. Spaces or indeed any legal characters in a font file name dont prevent them from working or make them incorrect. The is no "correct" filename for a font file.

I think I didn't explain properly. The Kobo doesn't care if there are spaces or not. The Check program in the Editor complains about spaces in the filenames. If Check "fixes" this or it's manually edited, the fonts then don't work in the Kobo, but did before!
Embed Fonts in the GUI of Conversion often adds spaces (Kobo doesn't care, but Check does). If I use Embed Fonts in the Editor it never puts spaces and creates a fonts.css. That works with Kobo and Check.
So
a.) The Conversion GUI and Editor GUI do fonts differently, the Editor version is compatible with Check.
b.) There is no FW issue on the Kobo, it works with or without spaces in the Font file name.
c.) If there are spaces and Check complains, and you fix it so that Check and Epub Check both pass, then the fonts don't work on the Kobo. If you ignore Check's complaint, the Kobo is fine.

Originally Posted by kovidgoyal

3) Opena bug report and attach a sample demonstrating the issue.

Where do I open a bug report?
The font-weight: 5; in the Gaelic font always happens with Embed Fonts (Conversion GUI or Editor, on the Editor there is a message about 400)
The list of panose numbers in a font css after embed font is rare. I don't remember which docx conversions caused it.


Thanks.
So:
1) I need to make sure Language Field in Metadata is not empty. I don't know why sometimes it is. I always check metadata and browse for cover after a docx import as they never have a cover.

2) For now I will delete fonts in Editor and use Embed via Editor, OR ignore Check's complaint about spaces or other illegal characters as "fixing" breaks it. Certainly there is a bug in Check as to how it automatically changes font names, but manually editing fails, so either leaving it alone or using Embed in the Editor is the solution. It's not the Kobo as it copes with either version of Embed Fonts (spaces or not).

3) Not a big deal. Simple to fix in fonts.css or page_styles.css and actually no ereader I have cares. I think only Check finds the numeric font weight or panose list a fault. Not sure about Epub Check.

[kovidgoyal]

check book simply renames the files and all references to them. I dont see how that could break anything. If the Kobo is indeed having trouble with it, that is a bug in its firmware. Just ignore the warning in check book, its a warning not an error. And the next version of calibre will replaces spaces in fonts when converting docx to keep epubcheck happy so the issue is moot anyway.

If you want to report bugs see: https://calibre-ebook.com/bugs

[Quoth]

Originally Posted by kovidgoyal

check book simply renames the files and all references to them. I dont see how that could break anything.

I don't see ow it can break it either. Also doing it by Check or carefully and manually fails (I checked that file names and CSS URL references looked the same). So I'm baffled.

Yet with the original names by the Conversion GUI Embed Fonts (which uses spaces) and the alternate names without spaces created by Editor GUI Embed Fonts both work on the Kobo.


Thanks.