[Webkit-unassigned] [Bug 18994] LANG/LC_ALL influences the result of element.style.opacity

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=18994





--- Comment #117 from Nikolas Zimmermann <zimmermann at kde.org>  2010-10-11 12:54:25 PST ---
(In reply to comment #116)
> Hi Nikolas,
> 
> I've been looking a bit at strings & number/string conversions lately, and had a couple of comments on this:
Thanks!

> 
> > Step #3) Kill String::format(), and it's platform specific implementations (like Qt did).
> 
> Yes!  We we absolutely should get rid of this.
Great.

> 
> > Step #2) Convert all users of String::format() to use String::number() + StringBuilder/Vector<Uchar> based string creation.
> 
> I think there is something slightly better we could do here.  StringBuilder is great if you're appending an arbitrary number of strings together, but being able to handle arbitrary amounts of data adds overhead (currently in the form of building the Vector, converting all C-strings to Strings.  In the near future we're likely to move from using a rope to an overcapacity based approach, which will remove these cost but possibly add some copying cost instead).
> 
> So one thing I've been meaning to do for a while is to add a String::cat() method to WTF::String.  Logically this would be a varargs function, but in practice since varargs provides no type information & only handles POD data, there would actually be multiple implementations, with methods handling something like 2-to-8 arguments.
> 
> In a trivial implementation all arguments would be 'const String&'s, and String::cat() could just wrap StringBuilder (rather than using StringBuilder directly) such that the internal implementation can be improved later.
Excellent, that would be really handy. Do you have already started coding this?

> 
> A better implementation we could make the arguments to cat be templated such that data could be added to the string without converting all arguments to String format first.  We already have this implemented in JavaScriptCore (and since we're close to unifying the string implementations we could ultimately fully share this code), in a set of methods called makeString.  These allow an arbitrary mix of UStrings and plain C-strings to be concatenated together, without first converting the C-strings to Strings.
I see, seems like it would be very wise to share the code in wtf/.

> 
> > Step #1) Patch String::number(double) to utilize wtf/DecimalNumber (which uses dtoa) to convert the double into a string. Apply some extra operations to make it mimic the String::format("%.6lg") output (cut off trailing zeros 1.5000 -> 1.5, leave integers unchanged 12.000 -> 12)
> 
> So, the question here is, what do we want String::number() to do?
Right.

> 
> * The rules for number to String conversion are different in different web technology specifications.
> * SVG has an uncommon requirement, in that it never overflows to an exponential representation.
> * HTML5 and ECMAScript agree on number-to-string conversion (in that the HTML5 spec requires ECMAScript conversion).
SVGs requirement is uncommon right, but we don't want this for the render path dumps, we definately want exponential numbers in the SVG DRT dumps.

> 
> My thought here is that we want String::number() to match HTML5/ECMAScript number-to-string conversion.  That is to say, like UString::number it should call WTF::numberToString in dtoa.h, which wraps DecimalNumber with appropriate bounds (<10^-6 & >=10^21) spilling to exponential representation.
Correct.

> 
> We should probably add a different method specifically for SVG's number-to-string behaviour.  This could be a free function within the svg code, taking a double and returning an String.  This method should also be able to use DecimalNumber in its implementation, but would likely chose to always call toStringDecimal, rather than toStringExponential.
I'm not sure if we need a special SVG method, I'd rather prefer an enum that describes how the number conversion should happen. The default should match HTML5/ECMAScript.

> 
> If elsewhere in the code we do require numbers formatted in a specific fashion (with a fixed number of digits, or significant figures) we should add methods to convert with appropriate constraints as necessary.  Hopefully we shouldn't need to mimic "%.6lg" behaviour, since this is not spec defined, probably doesn't match other browsers, and as such is hopefully not relied on anywhere.  Changing this should probably only fix spec compliance.
I tried to mimic the output initially to reduce the DRT changes for SVG, to see wheter the patch would fix the rounding issues between gtk 32bit and 64bit. It's not a requirment to mimic the output of String::format, agreed.

> 
> How does this sound?
Excellent! I'm happy to work on this, I hope you already wrote the String::cat stuff? If yes, I'd work on a String::number() implementation (like the one in my attached patch) which gives us more flexibility (add an FloatingPointConversionMode enum, with AvoidExponentials, RoundSiginifcantFigures, RoundDecimalPlaces modes, that can be OR'ed together, etc..)

How does this sound? :-)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.