Created attachment 156674 [details]
Test html file
Monospace font does not render in proper sizes:
I can't set a monospace font (eg: Courier) to 10CPI size. Theoretically Courier 12pt = 10CPI.
Steps to Reproduce:
Open the attachment in webkit
Notice that the text does not fill the grey box
Open the text html in Firefox 14, the block with 12pt Courier font exactly fills the box.
Open a microsoft word or libreoffice writer, create a text with 12pt Courier font, it prints exactly the same size, like firefox.
Build Date & Platform:
Linux 2.6.32-21-generic-pae #32-Ubuntu SMP Fri Apr 16 09:39:35 UTC 2010 i686 GNU/Linux
Additional Builds and Platforms:
Linux 3.2.0-27-generic-pae #43-Ubuntu SMP Fri Jul 6 15:06:05 UTC 2012 i686 i686 i386 GNU/Linux
Windows 7 (WebKit.exe#WebKit-r124698)
Created attachment 156675 [details]
Firefox 14 - renders right
Created attachment 156676 [details]
Created attachment 156678 [details]
If anyone can help, where can i start hacking the code, don't hesitate, please share with me!:)
Does anyone know what libs responsible for the font rendering in webkit on different operating systems?
The proper rendering in Firefox 14 and Internet Explorer 9 is done via new DirectWrite API. Before using DirectWrite the monospace rendering failed same way like webkit.
There is a list about different browsers and rendering engines in this article:
I tested every browser on windows. Just the browsers with DirectWrite engine renders properly.
Interesting. Have you tried compiling WebKit yourself? If you do, you can try to activate SUBPIXEL_LAYOUT and see if that helps. It looks like sizes are rounded poorly.
Im using webkit in Qt. I found a workaround:
Commenting out this row in this file makes the monospace fonts render correctly:
In my testing the workaround suggested in comment #7 also results in a general improvement in font kerning which was previously often very poor.
Any news on this?
Found it mentioned here: https://groups.google.com/forum/?fromgroups=#!topic/wkhtmltopdf-dev/SWLkI5eHi_4
Dear Allan Sandfeld Jensen!
I using Qt, so i suggested a workaround for it.
But the issue exists in webkit too (as you can see it in the screenshots)
I think there a two ways about this.
One, we need to establish if the bug #36532 still applies on Mac. Can we remove ForceIntegerMetrics.
Second, maybe ForceIntegerMetrics is being too aggressive, and should only force basic metrics to integers but not advances. I can confirm that removing the forced rounding on advances also solves this bug.
Created attachment 193767 [details]
Comment on attachment 193767 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=193767&action=review
Pierre, any opinion?
> +#if QT_VERSION < QT_VERSION_CHECK(5, 1, 0)
Please add a comment in the code explaining why the version guard is used.
Created attachment 193814 [details]
Comment on attachment 193814 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=193814&action=review
LGTM. That seems like the sensible approach (not affecting < 5.1 behaviour I mean)
> + // Kept enabled for Qt<5.1 to maintain stable baselines for 5.0.
coding style: Qt < 5.1. Ah wait no, I'm told it doesn't matter for comments ;)
> + // FIXME: Remove when we depend on Qt 5.1.
not sure if that was strictly necessary... But it'll go away with the whole ifdef chunk soon enough :)
Committed r146203: <http://trac.webkit.org/changeset/146203>
Committed r147544: <http://trac.webkit.org/changeset/147544>