Re: [webkit-dev] 8 Bit String Handling in Render Text Code

[Michael Saboff]

Got a patch for review to change the macro to ENABLE_8BIT_TEXTRUN.  
(https://bugs.webkit.org/attachment.cgi?id=168988action=review)

- Michael

On Oct 15, 2012, at 2:44 PM, Maciej Stachowiak m...@apple.com wrote:

 
 On Oct 15, 2012, at 9:56 AM, Michael Saboff msab...@apple.com wrote:
 
 I recently landed r131311 which adds code to handle 8-bit strings in the 
 render text path.  The code also puts HTML text into 8-bit strings.
 
 The reason for this announcement is that the handling of 8-bit text on the 
 render path is disabled on non-Mac platforms.  Most platforms have platform 
 specific text rendering code and that code needs to be updated to handle 
 8-bit text.  For Mac, the platform specific changes are for the complex text 
 rendering path only.  The changes involved converting the 8-bit text to a 
 16-bit String, adding the 16-bit string to the ComplexTextController so the 
 string won't be freed and using the contained 16-bit text with the rest of 
 the complex code unchanged.  See 
 ComplexTextController::collectComplexTextRuns() in 
 WebCore/platform/graphics/mac/ComplexTextController.cpp.
 
 The new define WTF_USE_8BIT_TEXTRUN is used to control the creation of 8-bit 
 TextRun objects.  When this define is not enabled, TextRun's will only 
 contain 16-bit text and current code should work correctly.  After platform 
 code is added to handle 8-bit text in platform specific code, that platform 
 should enable WTF_USE_8BIT_TEXTRUN.  Note that all platforms compile with 
 that define enabled, but it is likely they'll crash when running the tests.
 
 Minor technicality, but this should be an ENABLE flag, not USE. ENABLE is for 
 optional code in WebKit itself, USE is for optional external dependencies.
 
 Regards,
 Maciej
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Chromium Mountain Lion (Mac 10.8) baselines ...

[Dirk Pranke]

Hi all,

You can largely ignore this if you never modify Chromium baselines or
TestExpectations. But if you do modify them ...

I'm working on getting our new 10.8/MountainLion bot green. It looks
like Apple changed their text rendering a bit in the latest release
and so we need lots more baselines. In addition, the Chromium project
will currently fall back on the Apple baselines in platform/mac, and
we've decided that we probably shouldn't (so that Apple folks don't
have to worry about accidentally breaking the Chromium port when they
change their baselines in platform/mac), so I'll be landing copies
of those baselines into platform/chromium-mac as well.

So, you'll be seeing a lot of churn under LayoutTests :( Sorry !

Please *do not* modify
LayoutTests/platform/chromium-mac-mountainlion/TestExpectations
without coordinating with me. Largely, you should pretend it (and the
10.8 bot) don't exist until I say otherwise.

-- Dirk

PS. As an aside, this once again raises the question of whether
maintaining pixel tests (generally) is worth the cost to the project.
I would like to decrease our dependence on them, and am working on a
number of ideas that might help here, but don't have anything ready to
solve the problem right now. More on these efforts soon ...
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev