Akregator/kwebkitpart minimum font size?

[Thomas Tanghus]

On Monday 26 August 2013 22:37 Felix Miata wrote:
> On 2013-08-24 16:27 (GMT+0200) Thomas Tanghus composed:
> > I use kwebkitpart for embedding html/xhtml and hence that is what
> > Akregator
> > uses when opening a link in a tab.
> > 
> > Since the upgrade to KDE 4.11 the standard font is very small, and I
> > cannot
> > find where to change it.
> > I've tried to set the minimum font size both in Konqueror and in Rekonq,
> > but to no avail.
> > 
> > Is the some config file or anything for qtwebkit/kdewebkitpart?
> 
> I don't know, however....
> 
> I never use Akregator, and never install *webkit* intentionally. I suspect
> your problem is related to why I never install *webkit*. AFAICT, WebKit has
> no support for the "physical" sizes that KDE depends on. That is, fonts in
> KDE are sized in points. A point is a physical size, 1/72" on paper, and
> 1/72" on a PC screen only in cases where the DE's desktop pixel density
> matches the physical pixel density of the display. When they don't match,
> physical sizes essentially become logical sizes. Either way, these
> "physical" sizes are DPI dependent, that is, rendering a given "physical
> size" requires more pixels per glyph as display density increases beyond
> 96. In cases where density is below 96, most web browsers assume 96
> regardless what the physical density actually is.
> 
> In WebKit, instead of a point attempting to equal 1/72", it corresponds 1:1
> to a pixel. Whether a WebKit pixel is physical or logical is something I'm
> not currently up to speed on, but you can see what I'm talking about by
> loading http://fm.no-ip.com/Auth/dpi-screen-window.html in various browsers.
> I've not tested FF 22 or 23 yet to see what if any difference(s) from
> previous versions may exist, but at least up through 21 you'll see a match
> between Firefox (or SeaMonkey up through rv21) and Konq configured to use
> the KHTML engine, compared to Chromium or Rekonq or Konq configured to use
> WebKit. The latter render point sizes in pixels, because that's the way
> WebKit is. If your display is at or near 96 DPI, you won't see a difference
> among the five. However as display density is increased more than nominally
> above 96, pixel sized objects get progressively smaller physically, while
> point sized objects do not - until DPI reaches 192. Beyond that point
> things get more complicated, which I won't try to get into here, and likely
> does not apply to the problem you seem to be describing.

Thanks for the extensive explanation Felix.

My display is 96 DPI as reported by both xdpyinfo and X, and testing with the 
link you suggested, kwebkitpart does indeed report it wrongly as 105 DPI, 
while KHTML reports it as 96 DPI. Interestingly Rekonq, which uses qtwebkit, 
reports it correctly, so it must be possible to "instruct" webkit to use the 
correct DPI.

If I force fonts DPI to 96 kwebkitpart reports it correctly, while KHTML 
reports it as 0 DPI :D Both renders the same in Konqueror though, so it seems 
kwebkitpart isn't initialized with Konqs settings when used in Akregator.

-- 
Med venlig hilsen / Best Regards

Thomas Tanghus