b3nmore writes

The standard font for xubuntu is Droid Sans 10. With that font the results are way to large (looks like 17). I’ve set the gui fonts manually and it seems, that in the range from 10 - 18 the sizes are not correct. Furthermore this seems only an issue with that particular font and may be debian/ubuntu specific.

Any hint how to debug this? Maybe the correct font/size is for some reason not found and therefore replaced by another one.

medoc writes

Hi, I am running recoll on Ubuntu trusty, and I agree that there is something weird with the Droid Sans font sizes. What I am seeing is a huge gap when going from size 9 to 10, which I am not seeing, for example when using Century Schoolbook. OTOH, Century Schoolbook size 14 in Recoll looks about the same size as "Sans" size 10 in Emacs, and I am also seeing weird size gaps when changing fonts in the latter, so I guess that the whole situation is a huge mess. Maybe some issue with Screen DPI computations ? Anyway, I really don’t feel like getting into this, it really looks like a system issue.

If you want to look into it, the code for changing fonts is in uiprefs_w.cpp, look for "showFontDialog()", and the font is actually set in reslist.cpp, setFont() routine.

To make things even easier, the font in the result list is actually managed by webkit…

b3nmore writes

Hi, thanks for the quick reply. Another weird thing is, that the font/size in the sample widget of selection window is correct for the whole range. So are the fonts/size in the table view. That leaves only the (webkit rendered?) result list, which gets it wrong. Is it somehow possible to output the source for a result list?

medoc writes

I think that you could add something to print the text at line 732 in reslist.cpp. At this point, m_text should hold the whole page. But there are things which are not in the html, esp. the font is set in setFont() by QWebSettings calls.

b3nmore writes

The font size is too small for all fonts I’ve tested yet. By manually editing the font size in .config/Recoll.org/recoll.conf to preferred size + 3 (e.g. 13 if you acually want to have 10), I get the right size in the result list.

If I choose Droid Sans 10 via gui the font entries in .config/Recoll.org/recoll.conf are empty (maybe because it equals the system font): prefs\reslist\fontFamily= prefs\reslist\fontSize=0

By manually editing them to: prefs\reslist\fontFamily=Droid Sans prefs\reslist\fontSize=13 the result list is displayed with Droid Sans 10.

medoc writes

As you guessed, when the user choice equals the system default, I avoid trying to set anything at all, as it seems more reasonable to let the widget do the right thing.

This really looks like a webkit bug, and I’m not sure that it makes sense to change anything in recoll. After all, it’s possible to get the size wanted with a little trial and error, and any change I could make risks making more harm than good if webkit changes their ways ?

b3nmore writes

Hope you’re right. If it is a webkit bug, it should resolve itself eventually.

Can you confirm, that the font size is systematically off by 3? If so, this should be traceable somehow.

medoc writes

Actually it seems slightly more complicated than just off by 3. Here follow the sizes I seem to get on my display, running xubuntu trusty with the default font Droid Sans 10. This is all obtained by comparing string lengths by looking at the screen, so it can’t be very precise…

#!shell

8- >6
9- >6
10- >10
11- >8
16- >12
22- >16.5?

The only really ennoying thing is the weird position of the default size. Other than this, you can pretty much get what you want with reasonable trial and error. Maybe I am not doing what I should do in the code, maybe this is a webkit bug. I have to say that I’m not too keen on investigating this further…

b3nmore writes

> I have to say that I'm not too keen on investigating this further...

Don’t worry, maybe I can pin this down …

As to the default settings: It seems that resetting the fonts means qwebsettings defaults to times, 16. The rest depends on what fonts are installed on your system (e.g. I don’t have times, so the system falls back to sans; another system actually displays the results in times). Maybe this has historical reasons, even firefox sets its default font to serif, 16.

medoc writes

You’re right of course, it does default to a serif font. This must be an ancient HTML specification. I had not even noticed, I have a very bad eye for fonts.

This probably means that I should set the default explicitely instead of relying on webkit. And fix the offset-by-3, except that I’m not too sure if this could be dpi-dependant etc. And I do get slightly different results with different webkit versions. What a mess…

b3nmore writes

> This probably means that I should set the default explicitely instead of relying on webkit.

Agreed.

Concerning the offset, I’m currently investigating why fonts are rendered with the correct size, if the font size is specified in the html string (e.g., if one adds a style="font-size:10pt;" to the <table > tag in result paragraph format string). As I understand it, setting the default font via websettings and not specifying it in the html OR specifying it in the html itself should yield exactly the same result. I’ll keep you posted …

b3nmore writes

I’ve noticed commit 28a4231, and naturally it works for me now ;). There is just one further change I’d suggest: Set the string for reslistFontPB in UIPrefsDialog::resetReslistFont (line 430 in uiprefs_w.cpp) to something neutral, e.g. "Default font/size"; since there is no way to know, which font (size) will actually be used on a particular system.

And for the sake of completeness: I’ve posted the qwebview/qwebsettings font size issue with some test code on the qt forum (http://qt-project.org/forums/viewthread/50210/) and, after not having received an answer, on the qt bug tracker ( https://bugreports.qt-project.org/browse/QTBUG-43142). However, qtwebengine seems to be the future, so there might be not too much incentive to look into it.

medoc writes

I see. Lazyness is futile, I’ll fix the button message. But they’ll pry QWebElement from my dead fingers.

medoc writes