summaryrefslogtreecommitdiffstats
path: root/src/corelib/io
diff options
context:
space:
mode:
authorEskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>2015-02-27 14:11:24 +0100
committerEskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>2015-03-05 09:34:14 +0000
commitc29c6d9003b3ff67770dee66652dd2faecf842d5 (patch)
tree2ddd4d4965350d9938892fa35c6984c514d03524 /src/corelib/io
parentd70492d1eed698aa8ca362a276438c7eab9d63fb (diff)
OS X: Fix mixing writing systems, ligatures and text formatting
In QFontEngineMulti::stringToCMap() we call the primary engine's implementation of the same function. If this engine does not support the character in question, then it's supposed to clear the glyph array, otherwise there may be left-over junk in the glyph array from previous script items and the font selection algorithm will think it has already found a match for the character corresponding to the glyph position. The freetype engine, for instance, clears the respective entries in the array when it gets a 0 glyph from the font engine. In particular, this would happen when you had a ligature preceding an item that was shaped separately. The ligature (e.g. "fi") would set the first two slots of the glyph array, but later replace them with a single glyph. The next item would then get an offset of 1, i.e. pointing to the position in the glyph array where the glyph for i was originally contained. If this was not cleared, it would assume the primary engine supported the character. If the character was of an unsupported writing system, then you would get a box in place of it instead. [ChangeLog][OS X][Text] Fixed appending text with a different writing system and formatting to a latin ligature. Change-Id: Id8c81cdc8e2d8994cc1a999769fcae452c4f52ae Task-number: QTBUG-44708 Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Diffstat (limited to 'src/corelib/io')
0 files changed, 0 insertions, 0 deletions