Beta testing calibre 4

[kovidgoyal]

Originally Posted by DNSB

A minor nit for me is when editing metadata, I have to enable the toolbar to be able to bold/italic/etc. a selected text block instead of using the right click menu. The toolbar does offer quite a few functions but for me, it's not as convenient.

Added.

[kovidgoyal]

Originally Posted by thiago.eec

Hi, Kovid.

On the PDF conversion dialog, the tooltips for 'unit of measure' and 'size of paper' are showing unicode (u'a0', u'a1', etc), instead of plain text.

Thanks, fixed.

[kovidgoyal]

Originally Posted by thiago.eec

Hi, Kovid.

I'm still having trouble with cover images. Let me see if I got it right:

1. The book cover shown in the viewer is the IMAGE marked as cover on the OPF. Not the XHTML cover, right?
2. Calibre will show the cover as a full page image, keeping the aspect ratio. Is that also right?

Well, although that seems to be the general case, some books does not follow these rules. I have a bunch of books that display its cover aligned with the top of viewer, centered, but not filling the full height of the window.
If I start reducing the height of the window, when it 'touches' the image, then the the image will shrink as a full page image, i.e. keeping the aspect ratio while filling the whole window.

What is going on here?

That happens if the cover image is too small to fill the window. In this case it gets rendered at its natural size. It being aligned to the top of the window is a bug and will be fixed in the next release. Note that you will have to reload the book to see the fix.

[jackie_w]

Another difference I have noticed between 3.48 and calibre 4 beta is in display of non-embedded fonts. The attached image shows 3.48/3.99.5 on the left/right respectively.

The fancy dropcap is coded with this in the CSS:

font-family: "FZScript14", "FZ", serif;

As I already mentioned, this font is not embedded. My Kobos and Android readers are happy to find it in their custom fonts directories.

As you can see this also used to be true for the calibre Viewer. I copied FZScript14.ttf into my calibre config fonts directory and all worked fine.

I see the same difference (not a surprise) between versions in the calibre Editor.

I know this is only cosmetic, but it was nice-to-have. Is there any plan, or possibility, of this ever working in calibre 4?

[kovidgoyal]

No sadly webengine does not have any way to add custom fonts to it. If you install the custom fonts system wide rather than in your calibre fonts directory it should work.

[jackie_w]

Originally Posted by kovidgoyal

No sadly webengine does not have any way to add custom fonts to it. If you install the custom fonts system wide rather than in your calibre fonts directory it should work.

OK, that was easy and it works. Happy days

[thiago.eec]

Originally Posted by kovidgoyal

That happens if the cover image is too small to fill the window. In this case it gets rendered at its natural size. It being aligned to the top of the window is a bug and will be fixed in the next release. Note that you will have to reload the book to see the fix.

What is the limit to be considered 'too small'? I have covers with 600x800, 522x750, 500x700, that are all being displayed like this. Are those sizes really that small? They seem to be ok when in full page mode (using SVG).

[kovidgoyal]

There is no limit. It depends on the size of the viewer window. And there is nothing mysterious about it, it is simply that the new viewer will not stretch images only shrink them. If they are smaller than the window size, they will simply be displayed in the middle with whitespace around.

[thiago.eec]

Originally Posted by kovidgoyal

There is no limit. It depends on the size of the viewer window. And there is nothing mysterious about it, it is simply that the new viewer will not stretch images only shrink them. If they are smaller than the window size, they will simply be displayed in the middle with whitespace around.

Oh, I see. The viewer never enlarges the image, then.
Can't this behavior be altered by the user? Via preferences?

[kovidgoyal]

Originally Posted by thiago.eec

Oh, I see. The viewer never enlarges the image, then.
Can't this behavior be altered by the user? Via preferences?

Yeah eventually sure, but not at the moment.

[thiago.eec]

Originally Posted by kovidgoyal

Yeah eventually sure, but not at the moment.

Nice. That would be really good.

[jackie_w]

When using the Editor (Windows 10), and I have a lot of text files open in their own tabs, I often want to de-clutter and close all the tabs except for the one text file I'm working on.

What I've always done pre-beta is a right-click on the tab header to give me a mini-menu with 'Close tab' and 'Close other tabs'.

In the beta this right-click occasionally opens that mini-menu for me to pick 'Close other tabs', but just as often it doesn't give me the menu at all, it just auto-closes the one tab I wanted to keep open.

I can't figure out whether I'm right-clicking in the "wrong" part of the tab header or it's something else. I don't think my "right-click technique" has changed.

[kovidgoyal]

@jackie: Seems pretty consistent for me. This might be a change in Qt, since Qt wen tfrom 5.6 to 5.13

[jackie_w]

Originally Posted by kovidgoyal

@jackie: Seems pretty consistent for me. This might be a change in Qt, since Qt wen tfrom 5.6 to 5.13

I just tried again. I'm finding it impossible to guarantee bringing up the menu.

Anything you can suggest to avoid those moments, of which I'm anticipating many if it's a Qt thing?

[kovidgoyal]

No idea, sorry.