Re: [webkit-dev] HTML5 Parsing amp; MathML
On Tue, Nov 2, 2010 at 7:55 AM, David Carlisle d.p.carli...@gmail.com wrote: Personally I agree with you that this desire to make html elements forcibly close the surrounding math elements is entirely bogus, and it causes all sorts of problems in annotation-xml (where you really want nested html) but we failed to convince the html WG (or the html editor) of that and so ended up with a special case workaround for annotation-xml http://www.w3.org/Bugs/Public/show_bug.cgi?id=9887#c16 sometimes you have to take what you can get:-) I will take a look. However I don't agree that using the token elements as extension points is only necessary because of html parser strangeness, I think it leads to a cleaner design, and better fallback behaviour for systems that do not understand the foreign elements, in any case. Uncle! This will take some work to get working correctly with the implementation in WebKit. Right now, in XHTML documents with MathML, we get non-token XHTML for free. Within MathML token elements, this won't necessarily be the case. For example, the 'mo' element renderer as currently implemented won't preserve child rendering objects. We'll need to detect these situations and decide what to do. It would have been nice if MathML 3 had a foreign token element or indication via attribute typing so that we'd know that there is some kind of non-MathML content children that should be rendering according to the host language. We'll now have to have some kind of de-facto default set of rules that say that mixed content within a MathML is identified and handled slightly differently (especially if it contains things like SVG). That is, we'll need to detect things like: mathmo random text svg ... /svg more random text/mo/math While this example is rather pathological, it is still possible and should render as a stack of line boxes wrapped in the inline-block for the 'mo'. Also, this: mathmtext div .../div /mtext/math should be equivalent to the XHTML chunk: math xmlns='http://www.w3.org/1998/Math/MathML/'div xmlns='http://www.w3.org/1999/xhtml'.../div/math Both of the above examples should work today but once we implement the renderers for mtext/mi/mn etc. we'll need to take this foreign element rendering into account. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] coding style of #include statements
Currently, the style guidelines specify Includes of system headers must come after includes of other headers. But what about WebKit headers in arrow brackets? What is the correct style: #include ArgumentEncoder.h #include WorkItem.h #include wtf/HashSet.h #include wtf/OwnPtr.h #include QApplication #include QLocalServer or #include ArgumentEncoder.h #include WorkItem.h #include QApplication #include QLocalServer #include wtf/HashSet.h #include wtf/OwnPtr.h I prefere the first one because wtf/*.h aren't real system headers. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] coding style of #include statements
Hi, Now the second one is correct, because you should use angle brackets ... for system headers, and quote marks ... for non system headers. I think you should use wtf/HashSet.h. It is important, because searches order is different with ... and ...: http://gcc.gnu.org/onlinedocs/gcc-4.3.2//cpp/Include-Syntax.html#Include-Syntax #include file: 1.) -I ... directories 2.) -isystem .. directories 3.) standard system directories #include file: 1.) in the directory containing the current file 2.) -iquote 2.) -I 3.) -isystem 4.) standard system directories br, Ossy Patrick Roland Gansterer írta: Currently, the style guidelines specify Includes of system headers must come after includes of other headers. But what about WebKit headers in arrow brackets? What is the correct style: #include ArgumentEncoder.h #include WorkItem.h #include wtf/HashSet.h #include wtf/OwnPtr.h #include QApplication #include QLocalServer or #include ArgumentEncoder.h #include WorkItem.h #include QApplication #include QLocalServer #include wtf/HashSet.h #include wtf/OwnPtr.h I prefere the first one because wtf/*.h aren't real system headers. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] coding style of #include statements
Hi, on the contrary, I think ... is correct for WTF headers, because they are framework headers, and the include path where the WTF headers are, is added with -I, so the preprocessor will find them first. That's why almost all WTF includes use #include ... (there are only ~20 occasions where is used for WTF headers, which is wrong in my opinion, but not a coding style issue). The sentence in question should rather say something about -style and -style header includes to avoid confusion. That said, I think the correct order is: #include ArgumentEncoder.h #include WorkItem.h #include QApplication #include QLocalServer #include wtf/HashSet.h #include wtf/OwnPtr.h because alphabetical order matters here. BR, Andras On 11/03/2010 01:06 PM, Osztrogonac Csaba wrote: Hi, Now the second one is correct, because you should use angle brackets ... for system headers, and quote marks ... for non system headers. I think you should use wtf/HashSet.h. It is important, because searches order is different with ... and ...: http://gcc.gnu.org/onlinedocs/gcc-4.3.2//cpp/Include-Syntax.html#Include-Syntax #include file: 1.) -I ... directories 2.) -isystem .. directories 3.) standard system directories #include file: 1.) in the directory containing the current file 2.) -iquote 2.) -I 3.) -isystem 4.) standard system directories br, Ossy Patrick Roland Gansterer írta: Currently, the style guidelines specify Includes of system headers must come after includes of other headers. But what about WebKit headers in arrow brackets? What is the correct style: #include ArgumentEncoder.h #include WorkItem.h #include wtf/HashSet.h #include wtf/OwnPtr.h #include QApplication #include QLocalServer or #include ArgumentEncoder.h #include WorkItem.h #include QApplication #include QLocalServer #include wtf/HashSet.h #include wtf/OwnPtr.h I prefere the first one because wtf/*.h aren't real system headers. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing amp; MathML
Alex, Uncle! This will take some work to get working correctly with the implementation in WebKit. Sorry about that. Right now, in XHTML documents with MathML, we get non-token XHTML for free. Within MathML token elements, this won't necessarily be the case. For example, the 'mo' element renderer as currently implemented won't preserve child rendering objects. We'll need to detect these situations and decide what to do. Hmm, the mathml3 spec particularly recommends mtext as the extension point although I think it made sense to specify all the token elements for the parser, to switch to html rendering as it's much easier for validation or convention to restrict the document type than to extend the parser later. It would have been nice if MathML 3 had a foreign token element or indication via attribute typing so that we'd know that there is some kind of non-MathML content children that should be rendering according to the host language. But elsewhere you argue that such an element isn't needed and you should just be able to drop in other namespaced elements anywhere. in fact MathML3-in-(x)html does specify such an element, namely content of mo mi mtext are specified as being html. We'll now have to have some kind of de-facto default set of rules that say that mixed content within a MathML is identified and handled slightly differently (especially if it contains things like SVG). differently to what? Sorry I'm not sure I understand what you mean here, can't you just always view the content of mtext as inline html: it basically has the same content model as the content of an html span. SVG is allowed there just because it's allowed in any inline html. Clearly if you are looking up the content of mo in an operator dictionary that will only succeed if the mo only contains character data, but even if the mo does contain character data the dictionary lookup will fail in general if you have a finite dictionary and an arbitrary string as the content of the mo, so having it fail on mixed content isn't (in the abstract) any different, although I accept that an implementation may have different concerns. That is, we'll need to detect things like: mathmo random text svg ... /svg more random text/mo/math as above i don't see why you need to detect such things any more than you need to detect span random text svg ... /svg more random text/span In fact your original proposal was that mathspan.svg should just work, and so what is to stop mtext being treated exactly like span? David ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKitGtk app memory leaks , please help
After calling webkit_web_view_get_dom_document() and similar functions ( webkit_dom... * ) memory is not freed, what am I doing wrong? I wrote simple application which handle events ( load-started/load-finished/etc ) and make some changes in loaded page DOM content, so after loading several pages I have a lot of lost memory, no idea how to release it. I tried to use g_object_unref, but it destroys something.. -- View this message in context: http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk app memory leaks , please help
On 11/03/2010 03:52 PM, Fedor Kryukov wrote: After calling webkit_web_view_get_dom_document() and similar functions ( webkit_dom... * ) memory is not freed, what am I doing wrong? Can you provide us with a simple test application, open a bug, attach the test case to that? thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] coding style of #include statements
The intent is “sorted as the classic Unix command line sort tool would sort them”. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk app memory leaks , please help
I'm not sure is this a bug or my fail ) So this is diff to GtkLauncher ( webkitgtk 1.3.5 ) http://old.nabble.com/file/p30123917/main.diff main.diff its very simple. So when I use it with page which reloads fast I can see that it start to eat memory until swap is finished and app fails. I tried to add g_object_unref( document ); and it helps, but after some mouse movements over page app crashed and GDB shows this Program terminated with signal 11, Segmentation fault. #0 0x00457bb8 in g_type_interfaces () from /usr/lib/libgobject-2.0.so.0 (gdb) bt #0 0x00457bb8 in g_type_interfaces () from /usr/lib/libgobject-2.0.so.0 #1 0x0044ca07 in ?? () from /usr/lib/libgobject-2.0.so.0 #2 0x004531e8 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #3 0x006c55e1 in WebCore::GObjectEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) () from /usr/lib/libwebkitgtk-1.0.so.0 #4 0x0082ff35 in WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::VectorWebCore::RegisteredEventListener, 1u) () from /usr/lib/libwebkitgtk-1.0.so.0 #5 0x008305c7 in WebCore::EventTarget::fireEventListeners(WebCore::Event*) () from /usr/lib/libwebkitgtk-1.0.so.0 #6 0x0083e652 in WebCore::Node::handleLocalEvents(WebCore::Event*) () from /usr/lib/libwebkitgtk-1.0.so.0 #7 0x00840762 in WebCore::Node::dispatchGenericEvent(WTF::PassRefPtrWebCore::Event) () from /usr/lib/libwebkitgtk-1.0.so.0 #8 0x00840913 in WebCore::Node::dispatchEvent(WTF::PassRefPtrWebCore::Event) () from /usr/lib/libwebkitgtk-1.0.so.0 #9 0x008428c7 in WebCore::Node::dispatchMouseEvent(WTF::AtomicString const, int, int, int, int, int, int, bool, bool, bool, bool, bool, WebCore::Node*, WTF::PassRefPtrWebCore::Event) () from /usr/lib/libwebkitgtk-1.0.so.0 #10 0x00842de0 in WebCore::Node::dispatchMouseEvent(WebCore::PlatformMouseEvent const, WTF::AtomicString const, int, WebCore::Node*) () from /usr/lib/libwebkitgtk-1.0.so.0 #11 0x00abdc4b in WebCore::EventHandler::updateMouseEventTargetNode(WebCore::Node*, WebCore::PlatformMouseEvent const, bool) () from /usr/lib/libwebkitgtk-1.0.so.0 #12 0x00abe123 in WebCore::EventHandler::dispatchMouseEvent(WTF::AtomicString const, WebCore::Node*, bool, int, WebCore::PlatformMouseEvent const, bool) () from /usr/lib/libwebkitgtk-1.0.so.0 #13 0x00abf8ab in WebCore::EventHandler::handleMouseMoveEvent(WebCore::PlatformMouseEvent const, WebCore::HitTestResult*) () from /usr/lib/libwebkitgtk-1.0.so.0 #14 0x00abfc73 in WebCore::EventHandler::mouseMoved(WebCore::PlatformMouseEvent const) () from /usr/lib/libwebkitgtk-1.0.so.0 #15 0x00e1e6d9 in webkit_web_view_motion_event(_GtkWidget*, _GdkEventMotion*) () from /usr/lib/libwebkitgtk-1.0.so.0 #16 0x084d9424 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #17 0x0043b8b9 in ?? () from /usr/lib/libgobject-2.0.so.0 #18 0x0043d252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #19 0x004515e6 in ?? () from /usr/lib/libgobject-2.0.so.0 #20 0x00452c33 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #21 0x00453256 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #22 0x08606636 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #23 0x084d1a5d in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #24 0x084d2e07 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #25 0x0016639a in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #26 0x03e945e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #27 0x03e982d8 in ?? () from /lib/libglib-2.0.so.0 #28 0x03e98817 in g_main_loop_run () from /lib/libglib-2.0.so.0 #29 0x084d33c9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #30 0x080493aa in main () Holger Freyther-6 wrote: On 11/03/2010 03:52 PM, Fedor Kryukov wrote: After calling webkit_web_view_get_dom_document() and similar functions ( webkit_dom... * ) memory is not freed, what am I doing wrong? Can you provide us with a simple test application, open a bug, attach the test case to that? thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- View this message in context: http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30123917.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing amp; MathML
On Wed, Nov 3, 2010 at 7:49 AM, David Carlisle d.p.carli...@gmail.com wrote: It would have been nice if MathML 3 had a foreign token element or indication via attribute typing so that we'd know that there is some kind of non-MathML content children that should be rendering according to the host language. But elsewhere you argue that such an element isn't needed and you should just be able to drop in other namespaced elements anywhere. in fact MathML3-in-(x)html does specify such an element, namely content of mo mi mtext are specified as being html. Sure. ...didn't win that one! :) We have these token categories: * identifier (mi) * number (mn) * operator (mo) * text (mtext) * space (mspace) * string (ms) What if our use of some chunk of HTML doesn't fit in the categorization of the above? I would have been nice to have an ability to annotate foreign markup as some kind of layout element implemented in, say, HTML, and then potentially use embedded additional MathML for inner constructs. That way, things like accessibility would know that the foreign markup isn't a terminal structure of the Mathematics and might know (e.g. via ARIA) the role of the layout. ...so, that's what I meant. Just an idea ... We'll now have to have some kind of de-facto default set of rules that say that mixed content within a MathML is identified and handled slightly differently (especially if it contains things like SVG). differently to what? Sorry I'm not sure I understand what you mean here, can't you just always view the content of mtext as inline html: it basically has the same content model as the content of an html span. SVG is allowed there just because it's allowed in any inline html. Right. That's not different from what we'd expect. In section 3.2.1, it says: Token elements (other than mspace) should be rendered as their content, if any, (i.e. in the visual case, as a closely-spaced horizontal row of standard glyphs for the characters or images for the mglyphs in their content). Introduce a few SVG and HTML elements and then you have to make the assumptions about the children that are being rendered according to the normal rules (plus mglyph) so that this works: mi xyzzy div /div /mi Without any CSS, that 'div' will be a block whose rendering will cause a new block to be stacked within the inline. That's a consequence of my choice of using inline blocks and allowing the rendering of the 'div' to default to the current internal style within WebKit. I think that's the right choice but there might be other interpretations. For example, one could say that divs inside MathML have a display property of inline-block by default. That choice isn't covered by either MathML3 nor HTML5. I'm not sure it should be. That is, we'll need to detect things like: mathmo random text svg ... /svg more random text/mo/math as above i don't see why you need to detect such things any more than you need to detect Well, that's a consequence of building the rendering tree. Right now we don't have a special rendering object for token elements other than for 'mo'. In the case of operators, this becomes complicated due to operator stretching. It may work out to be straightforward but those feel like famous last words. That's all I meant. In fact your original proposal was that mathspan.svg should just work, and so what is to stop mtext being treated exactly like span? No much and hopefully it stays that way. At this point I'm not raising any issue except that I know that our 'mo' implementation is currently broken in this regard. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] XPath Issues?
As far as I can tell, these are the only filed issues with XPath implementation within WebKit: https://bugs.webkit.org/show_bug.cgi?id=26157 https://bugs.webkit.org/show_bug.cgi?id=12504 https://bugs.webkit.org/show_bug.cgi?id=13233 https://bugs.webkit.org/show_bug.cgi?id=12632 https://bugs.webkit.org/show_bug.cgi?id=12496 https://bugs.webkit.org/show_bug.cgi?id=36427 Anything else out there? Is it complete? I'm curious about how robust this implementation is and what enhancements have been filed for it. I'm also looking at what it would take to enhance this implementation to support XPath 2.0 ... -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk app memory leaks , please help
On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov y...@mail.ru wrote: After calling webkit_web_view_get_dom_document() and similar functions ( webkit_dom... * ) memory is not freed, what am I doing wrong? I wrote simple application which handle events ( load-started/load-finished/etc ) and make some changes in loaded page DOM content, so after loading several pages I have a lot of lost memory, no idea how to release it. I tried to use g_object_unref, but it destroys something.. -- View this message in context: http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html Sent from the Webkit mailing list archive at Nabble.com. The memory management of the GObject DOM bindings is still a work in progress (unfortunately!). We are trying to figure the best to automatically collect them, but for now you are correct in saying that they are essentially leaked until the process is over. See https://bugs.webkit.org/show_bug.cgi?id=40302 for some discussion on the topic. Our plan is to have this issue resolved before the next stable release in April. Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
03.11.2010, в 9:38, Alex Milowski написал(а): https://bugs.webkit.org/show_bug.cgi?id=26157 This is a request to implement an optimization, and one that doesn't seem particularly likely to provide material benefits. The optimization has an observable effect of reusing the same object though. https://bugs.webkit.org/show_bug.cgi?id=12504 Namespace nodes are pure evil, we shouldn't do that. https://bugs.webkit.org/show_bug.cgi?id=13233 This is a place to track future optimization ideas and performance tests. https://bugs.webkit.org/show_bug.cgi?id=12632 This is correct behavior, but Firefox has a bug. We could match Firefox, but with no actual sites known to be affected that doesn't seem important. https://bugs.webkit.org/show_bug.cgi?id=12496 An optimization opportunity. https://bugs.webkit.org/show_bug.cgi?id=36427 Unspecified behavior, different from Firefox. Anything else out there? Is it complete? I'm curious about how robust this implementation is and what enhancements have been filed for it. I think that the only actual bug we have was not on the list, https://bugs.webkit.org/show_bug.cgi?id=34231. JS wrappers should be preserved for all reachable nodes, which includes nodes in XPath result sets. I'm also looking at what it would take to enhance this implementation to support XPath 2.0 ... XPath 2.0 is not fully compatible with 1.0. JavaScript API for XPath doesn't provide a way to choose version - at least, it didn't when I last checked. So, we can't really support 2.0. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Wed, Nov 3, 2010 at 9:56 AM, Alexey Proskuryakov a...@webkit.org wrote: XPath 2.0 is not fully compatible with 1.0. JavaScript API for XPath doesn't provide a way to choose version - at least, it didn't when I last checked. So, we can't really support 2.0. I'm not sure that turns out to be a real issue considering this particular context. I've been shopping this idea around here at the W3C TPAC meeting and many of the incompatibilities may not occur within the context of the browser with a pre-built DOM. I'll have to dig further on that. It is certainly flawed that you can't choose a version. Unfortunately, there isn't a good way to test for XPath 1.0 but you can use an XPath 2.0 only expression to test for XPath 2.0 support. This should be fixed in the API. Also, we can't expect to stay at XPath 1.0 forever. At any rate, this would be considered completely experimental. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
03.11.2010, в 10:11, Alex Milowski написал(а): many of the incompatibilities may not occur within the context of the browser with a pre-built DOM. WebKit currently applies XSLT to document source, not to pre-built DOM. This is different from Firefox, but in strict compliance to the spec. We have separate XPath implementations for XSLT and for DOM bindings though, and the latter operates on DOM indeed (which is in accordance with http://www.w3.org/TR/2004/NOTE-DOM-Level-3-XPath-20040226/DOM3-XPath.html). Also, we can't expect to stay at XPath 1.0 forever. Actually, I see this situation as similar to XHTML 2.0. XPath is embedded into browsers both directly and via XSLT. Any incompatible specification featuring the same name is likely to end up as an academic exercise, dead on arrival. Looking at Mozilla bugs, they seem to have zero interest in XPath 2.0 and XSLT 2.0: https://bugzilla.mozilla.org/show_bug.cgi?id=396966 https://bugzilla.mozilla.org/show_bug.cgi?id=370173 - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Size Of Ruby Text?
Hi, As part of my work on ruby text enhancements, I'm implementing the option of not counting the height of the ruby text in the overall line height. As part of this, I wanted to play with changing the size of the ruby text. I'm trying to do this by changing the following lines in WebKit/WebCore/css/html.css: ruby rt { display: block; font-size: 60%; /* make slightly larger than 50% for better readability */ text-align: center; text-decoration: none; } However, when I change the font-size: attribute to, say, 50%, I don't see any difference in the size of the ruby text. (I even tried 25% just to be sure). Is this value being set somewhere else? Regards, Eric Mader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Any objections to switching to Xcode 3.2.4 or newer?
Please commit the updated Xcode project files. Dan On Oct 6, 2010, at 5:00 PM, Darin Adler da...@apple.com wrote: Hi folks. For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? It’s now showing up in Apple’s Software Update for all Xcode users, I believe. I ask because this adds a developmentRegion = English string to the project file but the older versions of Xcode remove that string. If we all agree to use the newer version, then we can let that string get checked in. If some of us are using the older version it will be frustrating because the string will be removed each time someone edits the project file with an older version and checks it in. If no one objects, we’ll start checking in the project files with developmentRegion in there. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Size Of Ruby Text?
WebKit enforces a minimum font size of 9px when no explicit font size is specified. This means that the font for rt cannot fall below 9px if it is relative to the user agent default. It may be that we want to consider modifying this minimum for ruby text and allow it to go below 9px though. I'm not sure. If you make a really big Ruby (e.g., ruby style=font-size:96px and then modify the font-size percentage on the rt, you should be able to see it take effect. We should probably just study real-world Japanese examples to see how small Ruby typically is allowed to get. If it can go below 9px and still be readable, we should perhaps consider allowing that. In terms of excluding Ruby text from the overall line height, I don't think the font-size of the rt is particularly relevant. You just want to hack the Ruby to turn the ruby text into overflow rather than having it be part of the overall height of the inline-block. dave (hy...@apple.com) On Nov 3, 2010, at 1:20 PM, Eric Mader wrote: Hi, As part of my work on ruby text enhancements, I'm implementing the option of not counting the height of the ruby text in the overall line height. As part of this, I wanted to play with changing the size of the ruby text. I'm trying to do this by changing the following lines in WebKit/WebCore/css/html.css: ruby rt { display: block; font-size: 60%; /* make slightly larger than 50% for better readability */ text-align: center; text-decoration: none; } However, when I change the font-size: attribute to, say, 50%, I don't see any difference in the size of the ruby text. (I even tried 25% just to be sure). Is this value being set somewhere else? Regards, Eric Mader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Size Of Ruby Text?
On Nov 3, 2010, at 8:56 AM, David Hyatt wrote: WebKit enforces a minimum font size of 9px when no explicit font size is specified. This means that the font for rt cannot fall below 9px if it is relative to the user agent default. It may be that we want to consider modifying this minimum for ruby text and allow it to go below 9px though. I'm not sure. Yes, that's probably what I'm seeing. I'm using default font size, which is probably 12pt. If you make a really big Ruby (e.g., ruby style=font-size:96px and then modify the font-size percentage on the rt, you should be able to see it take effect. We should probably just study real-world Japanese examples to see how small Ruby typically is allowed to get. If it can go below 9px and still be readable, we should perhaps consider allowing that. I'm sure the detailed spec. addresses this issue. I'll review it. In terms of excluding Ruby text from the overall line height, I don't think the font-size of the rt is particularly relevant. You just want to hack the Ruby to turn the ruby text into overflow rather than having it be part of the overall height of the inline-block. Of course. The website I was using has the line height set too tight for correct display this way, and I just wanted to try a smaller size to see if it looked better. OTOH, that site loads a style sheet that overrides the ruby text font-size to 6pt, so I can't easily override it, and its' probably displaying as 9pt anyhow. dave (hy...@apple.com) Regards, Eric On Nov 3, 2010, at 1:20 PM, Eric Mader wrote: Hi, As part of my work on ruby text enhancements, I'm implementing the option of not counting the height of the ruby text in the overall line height. As part of this, I wanted to play with changing the size of the ruby text. I'm trying to do this by changing the following lines in WebKit/WebCore/css/html.css: ruby rt { display: block; font-size: 60%; /* make slightly larger than 50% for better readability */ text-align: center; text-decoration: none; } However, when I change the font-size: attribute to, say, 50%, I don't see any difference in the size of the ruby text. (I even tried 25% just to be sure). Is this value being set somewhere else? Regards, Eric Mader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Size Of Ruby Text?
On Nov 3, 2010, at 2:05 PM, Eric Mader wrote: Of course. The website I was using has the line height set too tight for correct display this way, and I just wanted to try a smaller size to see if it looked better. OTOH, that site loads a style sheet that overrides the ruby text font-size to 6pt, so I can't easily override it, and its' probably displaying as 9pt anyhow. We honor small explicitly set font sizes. The 9px minimum is only enforced when it's impossible for the site to know what the real font size would have been, i.e., if you are relative to the user agent default. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Size Of Ruby Text?
In printing the standard is 50% of the base text. For larger point sizes like headings, the size of ruby is often smaller than 50%. http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3 So, how about we default to 50% and see how they come out. Glyphs designed for ruby are optimized for those small point sizes. It is possible on some screen resolutions we might want to make it a bit bigger but as screen resolution gets higher I think it makes more sense to stick to 50% following the standard in printing. - kida On 2010/11/03, at 12:05, Eric Mader wrote: On Nov 3, 2010, at 8:56 AM, David Hyatt wrote: WebKit enforces a minimum font size of 9px when no explicit font size is specified. This means that the font for rt cannot fall below 9px if it is relative to the user agent default. It may be that we want to consider modifying this minimum for ruby text and allow it to go below 9px though. I'm not sure. Yes, that's probably what I'm seeing. I'm using default font size, which is probably 12pt. If you make a really big Ruby (e.g., ruby style=font-size:96px and then modify the font-size percentage on the rt, you should be able to see it take effect. We should probably just study real-world Japanese examples to see how small Ruby typically is allowed to get. If it can go below 9px and still be readable, we should perhaps consider allowing that. I'm sure the detailed spec. addresses this issue. I'll review it. In terms of excluding Ruby text from the overall line height, I don't think the font-size of the rt is particularly relevant. You just want to hack the Ruby to turn the ruby text into overflow rather than having it be part of the overall height of the inline-block. Of course. The website I was using has the line height set too tight for correct display this way, and I just wanted to try a smaller size to see if it looked better. OTOH, that site loads a style sheet that overrides the ruby text font-size to 6pt, so I can't easily override it, and its' probably displaying as 9pt anyhow. dave (hy...@apple.com) Regards, Eric On Nov 3, 2010, at 1:20 PM, Eric Mader wrote: Hi, As part of my work on ruby text enhancements, I'm implementing the option of not counting the height of the ruby text in the overall line height. As part of this, I wanted to play with changing the size of the ruby text. I'm trying to do this by changing the following lines in WebKit/WebCore/css/html.css: ruby rt { display: block; font-size: 60%; /* make slightly larger than 50% for better readability */ text-align: center; text-decoration: none; } However, when I change the font-size: attribute to, say, 50%, I don't see any difference in the size of the ruby text. (I even tried 25% just to be sure). Is this value being set somewhere else? Regards, Eric Mader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Coding style change - Indentation of forward declarations in headers
On Nov 1, 2010, at 9:40 AM, Brady Eidson wrote: Thoughts? I agree that we should find a way to express the existing de facto rule clearly, rather than changing all the code to match the wording of the rule in the guidelines. I think the rule is something about indenting code inside namespace except when it’s the “main namespace” surrounding an entire source file (header or not). -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Size Of Ruby Text?
That document also states: When the size of base characters is very small (for e.g. smaller than seven points), ruby which is half the size, will be even more small and illegible. In such cases where the size of base characters is very small, ruby is not a suitable method of annotation. In those cases, consider other annotation methods such as adding the reading in parenthesis immediately after the base character. It also sounds like we need to special case Ruby elements and allow their font sizes to go down to about 5px instead of 9px. Anything lower, and you're getting to the point where ruby was unsuitable (according to the text above) anyway, since the base text was so small. I filed: https://bugs.webkit.org/show_bug.cgi?id=48942 dave (hy...@apple.com) On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote: In printing the standard is 50% of the base text. For larger point sizes like headings, the size of ruby is often smaller than 50%. http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3 So, how about we default to 50% and see how they come out. Glyphs designed for ruby are optimized for those small point sizes. It is possible on some screen resolutions we might want to make it a bit bigger but as screen resolution gets higher I think it makes more sense to stick to 50% following the standard in printing. - kida On 2010/11/03, at 12:05, Eric Mader wrote: On Nov 3, 2010, at 8:56 AM, David Hyatt wrote: WebKit enforces a minimum font size of 9px when no explicit font size is specified. This means that the font for rt cannot fall below 9px if it is relative to the user agent default. It may be that we want to consider modifying this minimum for ruby text and allow it to go below 9px though. I'm not sure. Yes, that's probably what I'm seeing. I'm using default font size, which is probably 12pt. If you make a really big Ruby (e.g., ruby style=font-size:96px and then modify the font-size percentage on the rt, you should be able to see it take effect. We should probably just study real-world Japanese examples to see how small Ruby typically is allowed to get. If it can go below 9px and still be readable, we should perhaps consider allowing that. I'm sure the detailed spec. addresses this issue. I'll review it. In terms of excluding Ruby text from the overall line height, I don't think the font-size of the rt is particularly relevant. You just want to hack the Ruby to turn the ruby text into overflow rather than having it be part of the overall height of the inline-block. Of course. The website I was using has the line height set too tight for correct display this way, and I just wanted to try a smaller size to see if it looked better. OTOH, that site loads a style sheet that overrides the ruby text font-size to 6pt, so I can't easily override it, and its' probably displaying as 9pt anyhow. dave (hy...@apple.com) Regards, Eric On Nov 3, 2010, at 1:20 PM, Eric Mader wrote: Hi, As part of my work on ruby text enhancements, I'm implementing the option of not counting the height of the ruby text in the overall line height. As part of this, I wanted to play with changing the size of the ruby text. I'm trying to do this by changing the following lines in WebKit/WebCore/css/html.css: ruby rt { display: block; font-size: 60%; /* make slightly larger than 50% for better readability */ text-align: center; text-decoration: none; } However, when I change the font-size: attribute to, say, 50%, I don't see any difference in the size of the ruby text. (I even tried 25% just to be sure). Is this value being set somewhere else? Regards, Eric Mader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk app memory leaks , please help
Thanks, As I understand this is a WebkitGtk bug only? So I can temporarily switch to QT WebKit to avoid leaks? Xan Lopez-3 wrote: On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov y...@mail.ru wrote: After calling webkit_web_view_get_dom_document() and similar functions ( webkit_dom... * ) memory is not freed, what am I doing wrong? I wrote simple application which handle events ( load-started/load-finished/etc ) and make some changes in loaded page DOM content, so after loading several pages I have a lot of lost memory, no idea how to release it. I tried to use g_object_unref, but it destroys something.. -- View this message in context: http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html Sent from the Webkit mailing list archive at Nabble.com. The memory management of the GObject DOM bindings is still a work in progress (unfortunately!). We are trying to figure the best to automatically collect them, but for now you are correct in saying that they are essentially leaked until the process is over. See https://bugs.webkit.org/show_bug.cgi?id=40302 for some discussion on the topic. Our plan is to have this issue resolved before the next stable release in April. Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- View this message in context: http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30126515.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk app memory leaks , please help
On Wed, Nov 3, 2010 at 1:20 PM, Fedor Kryukov y...@mail.ru wrote: Thanks, As I understand this is a WebkitGtk bug only? So I can temporarily switch to QT WebKit to avoid leaks? Possibly, but I don't know, you should ask them. Also, both bindings are not equally feature-complete (I believe in general the GTK+ ones have more features), so you'll have to be careful with that too. Xan Xan Lopez-3 wrote: On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov y...@mail.ru wrote: After calling webkit_web_view_get_dom_document() and similar functions ( webkit_dom... * ) memory is not freed, what am I doing wrong? I wrote simple application which handle events ( load-started/load-finished/etc ) and make some changes in loaded page DOM content, so after loading several pages I have a lot of lost memory, no idea how to release it. I tried to use g_object_unref, but it destroys something.. -- View this message in context: http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html Sent from the Webkit mailing list archive at Nabble.com. The memory management of the GObject DOM bindings is still a work in progress (unfortunately!). We are trying to figure the best to automatically collect them, but for now you are correct in saying that they are essentially leaked until the process is over. See https://bugs.webkit.org/show_bug.cgi?id=40302 for some discussion on the topic. Our plan is to have this issue resolved before the next stable release in April. Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- View this message in context: http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30126515.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Size Of Ruby Text?
I think 5px is way too small. Maybe 7 or 8 at least but even those are really hard to read in high-resolution displays. See demohttp://plexode.com/eval3/#ht=5px%3A%3Cruby%3E%3Crb%3E今日%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A5px%3B%22%3Eきょう%3C%2Frt%3E%3C%2Fruby%3Eは%3Cruby%3E%3Crb%3E良%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A5px%3B%22%3Eよ%3C%2Frt%3E%3C%2Fruby%3Eい%3Cruby%3E%3Crb%3E天気%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A5px%3B%22%3Eてんき%3C%2Frt%3E%3C%2Fruby%3E%3Cbr%3E%0A6px%3A%3Cruby%3E%3Crb%3E今日%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A6px%3B%22%3Eきょう%3C%2Frt%3E%3C%2Fruby%3Eは%3Cruby%3E%3Crb%3E良%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A6px%3B%22%3Eよ%3C%2Frt%3E%3C%2Fruby%3Eい%3Cruby%3E%3Crb%3E天気%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A6px%3B%22%3Eてんき%3C%2Frt%3E%3C%2Fruby%3E%3Cbr%3E%0A7px%3A%3Cruby%3E%3Crb%3E今日%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eきょう%3C%2Frt%3E%3C%2Fruby%3Eは%3Cruby%3E%3Crb%3E良%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eよ%3C%2Frt%3E%3C%2Fruby%3Eい%3Cruby%3E%3Crb%3E天気%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A7px%3B%22%3Eてんき%3C%2Frt%3E%3C%2Fruby%3E%3Cbr%3E%0A8px%3A%3Cruby%3E%3Crb%3E今日%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eきょう%3C%2Frt%3E%3C%2Fruby%3Eは%3Cruby%3E%3Crb%3E良%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eよ%3C%2Frt%3E%3C%2Fruby%3Eい%3Cruby%3E%3Crb%3E天気%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A8px%3B%22%3Eてんき%3C%2Frt%3E%3C%2Fruby%3E%3Cbr%3E%3C%2Fdiv%3Eohh=1ohj=1jt=ojh=1ojj=1ms=100oth=0otj=0cex=1 . - Ryosuke On Wed, Nov 3, 2010 at 12:47 PM, David Hyatt hy...@apple.com wrote: That document also states: When the size of base characters is very small (for e.g. smaller than seven points), ruby which is half the size, will be even more small and illegible. In such cases where the size of base characters is very small, ruby is not a suitable method of annotation. In those cases, consider other annotation methods such as adding the reading in parenthesis immediately after the base character. It also sounds like we need to special case Ruby elements and allow their font sizes to go down to about 5px instead of 9px. Anything lower, and you're getting to the point where ruby was unsuitable (according to the text above) anyway, since the base text was so small. I filed: https://bugs.webkit.org/show_bug.cgi?id=48942 dave (hy...@apple.com) On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote: In printing the standard is 50% of the base text. For larger point sizes like headings, the size of ruby is often smaller than 50%. http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3 So, how about we default to 50% and see how they come out. Glyphs designed for ruby are optimized for those small point sizes. It is possible on some screen resolutions we might want to make it a bit bigger but as screen resolution gets higher I think it makes more sense to stick to 50% following the standard in printing. - kida On 2010/11/03, at 12:05, Eric Mader wrote: On Nov 3, 2010, at 8:56 AM, David Hyatt wrote: WebKit enforces a minimum font size of 9px when no explicit font size is specified. This means that the font for rt cannot fall below 9px if it is relative to the user agent default. It may be that we want to consider modifying this minimum for ruby text and allow it to go below 9px though. I'm not sure. Yes, that's probably what I'm seeing. I'm using default font size, which is probably 12pt. If you make a really big Ruby (e.g., ruby style=font-size:96px and then modify the font-size percentage on the rt, you should be able to see it take effect. We should probably just study real-world Japanese examples to see how small Ruby typically is allowed to get. If it can go below 9px and still be readable, we should perhaps consider allowing that. I'm sure the detailed spec. addresses this issue. I'll review it. In terms of excluding Ruby text from the overall line height, I don't think the font-size of the rt is particularly relevant. You just want to hack the Ruby to turn the ruby text into overflow rather than having it be part of the overall height of the inline-block. Of course. The website I was using has the line height set too tight for correct display this way, and I just wanted to try a smaller size to see if it looked better. OTOH, that site loads a style sheet that overrides the ruby text font-size to 6pt, so I can't easily override it, and its' probably displaying as 9pt anyhow. dave (hy...@apple.com) Regards, Eric On Nov 3, 2010, at 1:20 PM, Eric Mader wrote: Hi, As part of my work on ruby text enhancements, I'm implementing the option of not counting the height of the ruby text in the overall line height. As part of this, I wanted to play with changing the size of the ruby text. I'm trying to do this by changing the following lines in WebKit/WebCore/css/html.css: ruby rt { display: block; font-size: 60%; /* make slightly larger than
Re: [webkit-dev] Size Of Ruby Text?
Yeah, that demo makes me think maybe 9px is fine after all. :) dave On Nov 3, 2010, at 3:56 PM, Ryosuke Niwa wrote: I think 5px is way too small. Maybe 7 or 8 at least but even those are really hard to read in high-resolution displays. See demo. - Ryosuke On Wed, Nov 3, 2010 at 12:47 PM, David Hyatt hy...@apple.com wrote: That document also states: When the size of base characters is very small (for e.g. smaller than seven points), ruby which is half the size, will be even more small and illegible. In such cases where the size of base characters is very small, ruby is not a suitable method of annotation. In those cases, consider other annotation methods such as adding the reading in parenthesis immediately after the base character. It also sounds like we need to special case Ruby elements and allow their font sizes to go down to about 5px instead of 9px. Anything lower, and you're getting to the point where ruby was unsuitable (according to the text above) anyway, since the base text was so small. I filed: https://bugs.webkit.org/show_bug.cgi?id=48942 dave (hy...@apple.com) On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote: In printing the standard is 50% of the base text. For larger point sizes like headings, the size of ruby is often smaller than 50%. http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3 So, how about we default to 50% and see how they come out. Glyphs designed for ruby are optimized for those small point sizes. It is possible on some screen resolutions we might want to make it a bit bigger but as screen resolution gets higher I think it makes more sense to stick to 50% following the standard in printing. - kida On 2010/11/03, at 12:05, Eric Mader wrote: On Nov 3, 2010, at 8:56 AM, David Hyatt wrote: WebKit enforces a minimum font size of 9px when no explicit font size is specified. This means that the font for rt cannot fall below 9px if it is relative to the user agent default. It may be that we want to consider modifying this minimum for ruby text and allow it to go below 9px though. I'm not sure. Yes, that's probably what I'm seeing. I'm using default font size, which is probably 12pt. If you make a really big Ruby (e.g., ruby style=font-size:96px and then modify the font-size percentage on the rt, you should be able to see it take effect. We should probably just study real-world Japanese examples to see how small Ruby typically is allowed to get. If it can go below 9px and still be readable, we should perhaps consider allowing that. I'm sure the detailed spec. addresses this issue. I'll review it. In terms of excluding Ruby text from the overall line height, I don't think the font-size of the rt is particularly relevant. You just want to hack the Ruby to turn the ruby text into overflow rather than having it be part of the overall height of the inline-block. Of course. The website I was using has the line height set too tight for correct display this way, and I just wanted to try a smaller size to see if it looked better. OTOH, that site loads a style sheet that overrides the ruby text font-size to 6pt, so I can't easily override it, and its' probably displaying as 9pt anyhow. dave (hy...@apple.com) Regards, Eric On Nov 3, 2010, at 1:20 PM, Eric Mader wrote: Hi, As part of my work on ruby text enhancements, I'm implementing the option of not counting the height of the ruby text in the overall line height. As part of this, I wanted to play with changing the size of the ruby text. I'm trying to do this by changing the following lines in WebKit/WebCore/css/html.css: ruby rt { display: block; font-size: 60%; /* make slightly larger than 50% for better readability */ text-align: center; text-decoration: none; } However, when I change the font-size: attribute to, say, 50%, I don't see any difference in the size of the ruby text. (I even tried 25% just to be sure). Is this value being set somewhere else? Regards, Eric Mader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Any objections to switching to Xcode 3.2.4 or newer?
On Oct 6, 2010, at 6:56 PM, Daniel Bates wrote: Please commit the updated Xcode project files. I did that for most projects a while ago. It seems one or two of the files have since lost their developmentRegion string. I did it again for all the projects just now. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Size Of Ruby Text?
Thank you Ryosuke. This is a good demo. 5px is only barely legible and I agree it is too small. 6px is legible but not fun to read. 7px looks reasonable lower bound to me. 12pt text with 96dpi would translates to 16px, 50% ruby would be 8px. 10.5pt which is often used by printed books is 14px, 50% ruby would be 7px. I do not think we should make the limit larger than 8px. The larger the ruby size gets the more often you need to put extra gaps in the base text, which makes the base text harder to read. See the example. - kida On 2010/11/03, at 14:01, David Hyatt wrote: Yeah, that demo makes me think maybe 9px is fine after all. :) dave On Nov 3, 2010, at 3:56 PM, Ryosuke Niwa wrote: I think 5px is way too small. Maybe 7 or 8 at least but even those are really hard to read in high-resolution displays. See demo. - Ryosuke On Wed, Nov 3, 2010 at 12:47 PM, David Hyatt hy...@apple.com wrote: That document also states: When the size of base characters is very small (for e.g. smaller than seven points), ruby which is half the size, will be even more small and illegible. In such cases where the size of base characters is very small, ruby is not a suitable method of annotation. In those cases, consider other annotation methods such as adding the reading in parenthesis immediately after the base character. It also sounds like we need to special case Ruby elements and allow their font sizes to go down to about 5px instead of 9px. Anything lower, and you're getting to the point where ruby was unsuitable (according to the text above) anyway, since the base text was so small. I filed: https://bugs.webkit.org/show_bug.cgi?id=48942 dave (hy...@apple.com) On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote: In printing the standard is 50% of the base text. For larger point sizes like headings, the size of ruby is often smaller than 50%. http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3 So, how about we default to 50% and see how they come out. Glyphs designed for ruby are optimized for those small point sizes. It is possible on some screen resolutions we might want to make it a bit bigger but as screen resolution gets higher I think it makes more sense to stick to 50% following the standard in printing. - kida On 2010/11/03, at 12:05, Eric Mader wrote: On Nov 3, 2010, at 8:56 AM, David Hyatt wrote: WebKit enforces a minimum font size of 9px when no explicit font size is specified. This means that the font for rt cannot fall below 9px if it is relative to the user agent default. It may be that we want to consider modifying this minimum for ruby text and allow it to go below 9px though. I'm not sure. Yes, that's probably what I'm seeing. I'm using default font size, which is probably 12pt. If you make a really big Ruby (e.g., ruby style=font-size:96px and then modify the font-size percentage on the rt, you should be able to see it take effect. We should probably just study real-world Japanese examples to see how small Ruby typically is allowed to get. If it can go below 9px and still be readable, we should perhaps consider allowing that. I'm sure the detailed spec. addresses this issue. I'll review it. In terms of excluding Ruby text from the overall line height, I don't think the font-size of the rt is particularly relevant. You just want to hack the Ruby to turn the ruby text into overflow rather than having it be part of the overall height of the inline-block. Of course. The website I was using has the line height set too tight for correct display this way, and I just wanted to try a smaller size to see if it looked better. OTOH, that site loads a style sheet that overrides the ruby text font-size to 6pt, so I can't easily override it, and its' probably displaying as 9pt anyhow. dave (hy...@apple.com) Regards, Eric On Nov 3, 2010, at 1:20 PM, Eric Mader wrote: Hi, As part of my work on ruby text enhancements, I'm implementing the option of not counting the height of the ruby text in the overall line height. As part of this, I wanted to play with changing the size of the ruby text. I'm trying to do this by changing the following lines in WebKit/WebCore/css/html.css: ruby rt { display: block; font-size: 60%; /* make slightly larger than 50% for better readability */ text-align: center; text-decoration: none; } However, when I change the font-size: attribute to, say, 50%, I don't see any difference in the size of the ruby text. (I even tried 25% just to be sure). Is this value being set somewhere else? Regards, Eric Mader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] Size Of Ruby Text?
Does this work? http://plexode.com/eval3/#ht=%3Cdiv%20style%3D%22font-size%3A16px%3B%22%3E%0A16px-8px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A8px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%0A16px-9px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A9px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%3Cbr%3E%0A%3C%2Fdiv%3E%0A%0A%3Cdiv%20style%3D%22font-size%3A14px%3B%22%3E%0A14px-7px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A7px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%0A14px-9px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A8px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%0A%3C%2Fdiv%3E%0Aohh=1ohj=1jt=ojh=1ojj=1ms=100oth=0otj=0cex=1 According to Choice of Size for Ruby Characters in Requirements for Japanese Text Layout: (note 2) When the size of base characters is very small (for e.g. smaller than seven points), ruby which is half the size, will be even more small and illegible. In such cases where the size of base characters is very small, ruby is not a suitable method of annotation. In those cases, consider other annotation methods such as adding the reading in parenthesis immediately after the base character. - kida On 2010/11/03, at 15:21, Ryosuke Niwa wrote: Hi Yasuko, Somehow your example isn't working. Could you copy paste the HTML? - Ryosuke On Wed, Nov 3, 2010 at 3:11 PM, Yasuo Kida k...@apple.com wrote: Thank you Ryosuke. This is a good demo. 5px is only barely legible and I agree it is too small. 6px is legible but not fun to read. 7px looks reasonable lower bound to me. 12pt text with 96dpi would translates to 16px, 50% ruby would be 8px. 10.5pt which is often used by printed books is 14px, 50% ruby would be 7px. I do not think we should make the limit larger than 8px. The larger the ruby size gets the more often you need to put extra gaps in the base text, which makes the base text harder to read. See the example. - kida On 2010/11/03, at 14:01, David Hyatt wrote: Yeah, that demo makes me think maybe 9px is fine after all. :) dave On Nov 3, 2010, at 3:56 PM, Ryosuke Niwa wrote: I think 5px is way too small. Maybe 7 or 8 at least but even those are really hard to read in high-resolution displays. See demo. - Ryosuke On Wed, Nov 3, 2010 at 12:47 PM, David Hyatt hy...@apple.com wrote: That document also states: When the size of base characters is very small (for e.g. smaller than seven points), ruby which is half the size, will be even more small and illegible. In such cases where the size of base characters is very small, ruby is not a suitable method of annotation. In those cases, consider other annotation methods such as adding the reading in parenthesis immediately after the base character. It also sounds like we need to special case Ruby elements and allow their font sizes to go down to about 5px instead of 9px. Anything lower, and you're getting to the point where ruby was unsuitable (according to the text above) anyway, since the base text was so small. I filed: https://bugs.webkit.org/show_bug.cgi?id=48942 dave (hy...@apple.com) On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote: In printing the standard is 50% of the base text. For larger point sizes like headings,
Re: [webkit-dev] Size Of Ruby Text?
Right. It is partly because webkit currently does not use glyphs that are designed for ruby. I would not worry this too much as with 14px many kanjis are only barely legible in anyway without the context. The lower bound for ruby can be 8px for base 16px = 12pt in 96dpi. I am reluctant to raise it to 9 px. It would be more important to keep the 50% ratio until we hit the threshold to avoid too many white spaces between base characters. - kida On 2010/11/03, at 15:49, Ryosuke Niwa wrote: Yes that works. With anything below 9px, it's really hard to differentiate 濁音 (ばびぶべぼ) 半濁音 (ぱぴぷぺぼ). - Ryosuke 2010/11/3 Yasuo Kida k...@apple.com Does this work? http://plexode.com/eval3/#ht=%3Cdiv%20style%3D%22font-size%3A16px%3B%22%3E%0A16px-8px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A8px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%0A16px-9px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A9px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%3Cbr%3E%0A%3C%2Fdiv%3E%0A%0A%3Cdiv%20style%3D%22font-size%3A14px%3B%22%3E%0A14px-7px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A7px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%0A14px-9px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A8px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%0A%3C%2Fdiv%3E%0Aohh=1ohj=1jt=ojh=1ojj=1ms=100oth=0otj=0cex=1 According to Choice of Size for Ruby Characters in Requirements for Japanese Text Layout: (note 2) When the size of base characters is very small (for e.g. smaller than seven points), ruby which is half the size, will be even more small and illegible. In such cases where the size of base characters is very small, ruby is not a suitable method of annotation. In those cases, consider other annotation methods such as adding the reading in parenthesis immediately after the base character. - kida On 2010/11/03, at 15:21, Ryosuke Niwa wrote: Hi Yasuko, Somehow your example isn't working. Could you copy paste the HTML? - Ryosuke On Wed, Nov 3, 2010 at 3:11 PM, Yasuo Kida k...@apple.com wrote: Thank you Ryosuke. This is a good demo. 5px is only barely legible and I agree it is too small. 6px is legible but not fun to read. 7px looks reasonable lower bound to me. 12pt text with 96dpi would translates to 16px, 50% ruby would be 8px. 10.5pt which is often used by printed books is 14px, 50% ruby would be 7px. I do not think we should make the limit larger than 8px. The larger the ruby size gets the more often you need to put extra gaps in the base text, which makes the base text harder to read. See the example. - kida On 2010/11/03, at 14:01, David Hyatt wrote: Yeah, that demo makes me think maybe 9px is fine after all. :) dave On Nov 3, 2010, at 3:56 PM, Ryosuke Niwa wrote: I think 5px is way too small. Maybe 7 or 8 at least but even those are really hard to read in high-resolution displays. See demo. - Ryosuke On Wed, Nov 3, 2010 at 12:47 PM, David Hyatt hy...@apple.com wrote: That document also states: When the size of base characters is very small (for e.g. smaller than seven points), ruby which is half the size, will be even more small and illegible. In such cases where the size of base characters is very small, ruby is not a suitable