Created attachment 65071 [details] Screenshot showing this bug Since there is no way to pass the Qt::TextBypassShaping flag to QPainterPath::addText(), what we stroke may differ from what we fill (and what we paint as a shadow.) See the attached image for an example of this bug.
Created attachment 65072 [details] Proposed patch
Even with the patch, does that mean if I fill the text first and then stroke it, they will not be the same? Hopefully drawTextCommon is never called twice with such order.
(In reply to comment #2) > Even with the patch, does that mean if I fill the text first and then stroke it, they will not be the same? > Hopefully drawTextCommon is never called twice with such order. Fudge! You're right. The bug can still be triggered by separate calls to strokeText() and fillText() on a CanvasRenderingContext2D.
Comment on attachment 65072 [details] Proposed patch Self r-, need to fix this for CRC2D strokeText()/fillText(), too.
Created attachment 65091 [details] Proposed patch v2 To avoid the problem when using the Canvas API, I've added a "shouldForceComplexShaping" property to Font (Qt-only.)
I think that using forceComplexShaping would be shorter and have the same meaning as shouldForceComplexShaping, though it doesn't matter much. Still looks good to me.
Created attachment 65101 [details] Proposed patch v3 Talked to Simon (IRL) about this and he suggested that I use Font::setCodePath() instead, which is much cleaner than adding a platform-specific member to Font.
Comment on attachment 65101 [details] Proposed patch v3 A lot cleaner indeed!
(In reply to comment #8) > (From update of attachment 65101 [details]) > A lot cleaner indeed! Still maybe some comments in the ifdef's would be nice!
(In reply to comment #9) > Still maybe some comments in the ifdef's would be nice! Will land with comments. Thanks for the review <3
Committed r65801: <http://trac.webkit.org/changeset/65801>
Revision r65801 cherry-picked into qtwebkit-2.1 with commit 1a184f3f6e088a4d5e4afd5ed71d3cb8d07a5a53