Re: [webkit-dev] Ruby Text Enhancements

2010-10-13 Thread Roland Steiner
Thanks a lot for the review! The patch has landed and should be a much
cleaner foundation for generated content (which may also have to be
overlapped).

Speaking of general ruby text enhancements: there is a new bug
https://bugs.webkit.org/show_bug.cgi?id=47596 regarding the ruby display
types. The previous consensus was that we shouldn't implement them (yet).
Furthermore, the expectation in that bug description would run contrary to
the spec anyway: setting rt to 'display: inline' should display it as ruby
text (rather than inline). Do you guys have any suggestions on this?

Cheers,

- Roland

On Thu, Oct 7, 2010 at 2:14 PM, Roland Steiner rolandstei...@google.comwrote:

 Seeing that this is progressing ad a quick pace, could I entice some kind
 reviewer to r+ my patch for bug
 https://bugs.webkit.org/show_bug.cgi?id=41040 before I get (another...)
 mid-air collision?

 ^_^; Roland


 On Wed, Oct 6, 2010 at 5:34 PM, Eric Mader ema...@apple.com wrote:


 On Oct 5, 2010, at 6:25 PM, David Hyatt wrote:

 On Oct 5, 2010, at 7:33 PM, Eric Mader wrote:


 On Sep 24, 2010, at 8:02 PM, David Hyatt wrote:

 This is a tough problem.  It seems like you have to get involved in the
 line layout code e.g., findNextLineBreak in order to really do the right
 thing.  findNextLineBreak uses an iterator that walks the objects, so it's
 easier to tell what text came before you and what text comes after you.  You
 can also tell whether or not that text will even fit on the line and
 possibly do the margin hacking there.


 I just did a prototype that checks for a RenderRubyRun in the isReplaced()
 code inside findNextLineBreak and calls a method on the RenderRubyRun that
 takes the last and the next object and sets negative margins by calling
 setMarginLeft() and setMarginRight(). I stepped through this code and it
 computes the correct margins, but the margins don't seem to take - the ruby
 doesn't overlap the surrounding text.

 Guessing that some other code is resetting the margins, I modified the
 code to cache the computed margins in the RenderRubyRun object and return
 the cached values through subclassed marginLeft() and marginRight() methods.
 With this change, the ruby displays as I would expect.


 It's probably RenderBlockLineLayout line 348 getting you in trouble (
 computeInlineDirectionPositionsForLine).  computeLogicalWidth is called
 again, and that will recompute the left/right margins and blow away the
 changes you made to them.  I have no idea why that call is there.  It should
 not be necessary, but maybe there's something subtle I'm missing.  You could
 try removing it, and see if that fixes the problem (it should).


 Yes, that did the trick! I haven't noticed any obvious problems with that
 line removed, but I haven't done much testing yet.

 dave
 (hy...@apple.com)


 Regards,
 Eric

 ___
 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] Ruby Text Enhancements

2010-10-06 Thread Eric Mader

On Oct 5, 2010, at 6:25 PM, David Hyatt wrote:

 On Oct 5, 2010, at 7:33 PM, Eric Mader wrote:
 
 
 On Sep 24, 2010, at 8:02 PM, David Hyatt wrote:
 
 This is a tough problem.  It seems like you have to get involved in the 
 line layout code e.g., findNextLineBreak in order to really do the right 
 thing.  findNextLineBreak uses an iterator that walks the objects, so it's 
 easier to tell what text came before you and what text comes after you.  
 You can also tell whether or not that text will even fit on the line and 
 possibly do the margin hacking there.
 
 I just did a prototype that checks for a RenderRubyRun in the isReplaced() 
 code inside findNextLineBreak and calls a method on the RenderRubyRun that 
 takes the last and the next object and sets negative margins by calling 
 setMarginLeft() and setMarginRight(). I stepped through this code and it 
 computes the correct margins, but the margins don't seem to take - the ruby 
 doesn't overlap the surrounding text.
 
 Guessing that some other code is resetting the margins, I modified the code 
 to cache the computed margins in the RenderRubyRun object and return the 
 cached values through subclassed marginLeft() and marginRight() methods. 
 With this change, the ruby displays as I would expect.
 
 It's probably RenderBlockLineLayout line 348 getting you in trouble 
 (computeInlineDirectionPositionsForLine).  computeLogicalWidth is called 
 again, and that will recompute the left/right margins and blow away the 
 changes you made to them.  I have no idea why that call is there.  It should 
 not be necessary, but maybe there's something subtle I'm missing.  You could 
 try removing it, and see if that fixes the problem (it should).

Yes, that did the trick! I haven't noticed any obvious problems with that line 
removed, but I haven't done much testing yet.

 dave
 (hy...@apple.com)

Regards,
Eric___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Ruby Text Enhancements

2010-10-06 Thread Roland Steiner
Seeing that this is progressing ad a quick pace, could I entice some kind
reviewer to r+ my patch for bug
https://bugs.webkit.org/show_bug.cgi?id=41040 before I get (another...)
mid-air collision?

^_^; Roland


On Wed, Oct 6, 2010 at 5:34 PM, Eric Mader ema...@apple.com wrote:


 On Oct 5, 2010, at 6:25 PM, David Hyatt wrote:

 On Oct 5, 2010, at 7:33 PM, Eric Mader wrote:


 On Sep 24, 2010, at 8:02 PM, David Hyatt wrote:

 This is a tough problem.  It seems like you have to get involved in the
 line layout code e.g., findNextLineBreak in order to really do the right
 thing.  findNextLineBreak uses an iterator that walks the objects, so it's
 easier to tell what text came before you and what text comes after you.  You
 can also tell whether or not that text will even fit on the line and
 possibly do the margin hacking there.


 I just did a prototype that checks for a RenderRubyRun in the isReplaced()
 code inside findNextLineBreak and calls a method on the RenderRubyRun that
 takes the last and the next object and sets negative margins by calling
 setMarginLeft() and setMarginRight(). I stepped through this code and it
 computes the correct margins, but the margins don't seem to take - the ruby
 doesn't overlap the surrounding text.

 Guessing that some other code is resetting the margins, I modified the code
 to cache the computed margins in the RenderRubyRun object and return the
 cached values through subclassed marginLeft() and marginRight() methods.
 With this change, the ruby displays as I would expect.


 It's probably RenderBlockLineLayout line 348 getting you in trouble (
 computeInlineDirectionPositionsForLine).  computeLogicalWidth is called
 again, and that will recompute the left/right margins and blow away the
 changes you made to them.  I have no idea why that call is there.  It should
 not be necessary, but maybe there's something subtle I'm missing.  You could
 try removing it, and see if that fixes the problem (it should).


 Yes, that did the trick! I haven't noticed any obvious problems with that
 line removed, but I haven't done much testing yet.

 dave
 (hy...@apple.com)


 Regards,
 Eric

 ___
 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] Ruby Text Enhancements

2010-10-05 Thread Eric Mader

On Sep 24, 2010, at 8:02 PM, David Hyatt wrote:

 This is a tough problem.  It seems like you have to get involved in the line 
 layout code e.g., findNextLineBreak in order to really do the right thing.  
 findNextLineBreak uses an iterator that walks the objects, so it's easier to 
 tell what text came before you and what text comes after you.  You can also 
 tell whether or not that text will even fit on the line and possibly do the 
 margin hacking there.

I just did a prototype that checks for a RenderRubyRun in the isReplaced() code 
inside findNextLineBreak and calls a method on the RenderRubyRun that takes the 
last and the next object and sets negative margins by calling setMarginLeft() 
and setMarginRight(). I stepped through this code and it computes the correct 
margins, but the margins don't seem to take - the ruby doesn't overlap the 
surrounding text.

Guessing that some other code is resetting the margins, I modified the code to 
cache the computed margins in the RenderRubyRun object and return the cached 
values through subclassed marginLeft() and marginRight() methods. With this 
change, the ruby displays as I would expect.

Does anybody have any idea what code resetting the margins, and what I need to 
do to talk it out of doing this?

Regards,
Eric


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


Re: [webkit-dev] Ruby Text Enhancements

2010-10-05 Thread David Hyatt
On Oct 5, 2010, at 7:33 PM, Eric Mader wrote:

 
 On Sep 24, 2010, at 8:02 PM, David Hyatt wrote:
 
 This is a tough problem.  It seems like you have to get involved in the line 
 layout code e.g., findNextLineBreak in order to really do the right thing.  
 findNextLineBreak uses an iterator that walks the objects, so it's easier to 
 tell what text came before you and what text comes after you.  You can also 
 tell whether or not that text will even fit on the line and possibly do the 
 margin hacking there.
 
 I just did a prototype that checks for a RenderRubyRun in the isReplaced() 
 code inside findNextLineBreak and calls a method on the RenderRubyRun that 
 takes the last and the next object and sets negative margins by calling 
 setMarginLeft() and setMarginRight(). I stepped through this code and it 
 computes the correct margins, but the margins don't seem to take - the ruby 
 doesn't overlap the surrounding text.
 
 Guessing that some other code is resetting the margins, I modified the code 
 to cache the computed margins in the RenderRubyRun object and return the 
 cached values through subclassed marginLeft() and marginRight() methods. With 
 this change, the ruby displays as I would expect.

It's probably RenderBlockLineLayout line 348 getting you in trouble 
(computeInlineDirectionPositionsForLine).  computeLogicalWidth is called again, 
and that will recompute the left/right margins and blow away the changes you 
made to them.  I have no idea why that call is there.  It should not be 
necessary, but maybe there's something subtle I'm missing.  You could try 
removing it, and see if that fixes the problem (it should).

dave
(hy...@apple.com)



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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-28 Thread David Hyatt
On Sep 27, 2010, at 3:40 PM, Eric Mader wrote:

 
 Are you saying that subclassing computeLogicalWidth() would still mean that 
 I'm computing the margins at the initial calculation time?
 

You'd be computing them whenever the ruby run's layout changed.  The problem 
with that is if you're setting margins based off surrounding content, you're 
not going to get a layout just because your surroundings changed.

 It just doesn't seem like you can deal with all the corner cases without 
 integrating right into line layout.  I don't see how else you can know if 
 you have adequate available space to actually overhang without knowing what 
 you've seen so far on the line and how much space you have left on the line.
 
 This would require special-casing the ruby blocks in line layout code, right? 
 I was trying to avoid this, hoping that I could just extend the existing ruby 
 objects.
 

Right.  It's kind of a minor miracle that Ruby has gotten this far without 
having to do this though. :)

 This method makes several assumptions that I'm not 100% sure are always 
 safe:
 * That a RenderRuby object holds only 1 RenderRubyRun object.
 
 I believe you can have multiple RenderRubyRuns inside a single RenderRuby.
 
 http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-ruby-element
 
 The ruby element allows one or more spans of phrasing content to be marked 
 with ruby annotations.
 
 * That the text for the ruby text and ruby base are always the direct 
 child of the RenderRubyText and RenderRubyBase object.
 
 I doubt that's a valid assumption.  I assume that you can have a content 
 tree of markup underneath a RenderRubyText and a RenderRubyBase, e.g., if 
 you put in some i and some b.  Anyway, I think you could just ask for 
 the width() of the rubyText() and rubyBase() objects themselves rather than 
 drilling down into their subtrees.
 
 I couldn't figure out how to ask the RenderRubyText and RenderRubyRun objects 
 for their width. They don't support the width() method. What method should I 
 call?
 

They should.  They are RenderBlocks, so they should have width() methods.  You 
may have just been getting bad results because you hooked in before the width 
was computed.  That's why computeLogicalWidth subclassing would work better for 
you.  Let the base class set up the margins and width, and then you override.

dave
(hy...@apple.com)

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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-28 Thread Yasuo Kida

On 2010/09/28, at 10:11, David Hyatt wrote:
 On Sep 27, 2010, at 3:40 PM, Eric Mader wrote:
 Are you saying that subclassing computeLogicalWidth() would still mean that 
 I'm computing the margins at the initial calculation time?
 
 You'd be computing them whenever the ruby run's layout changed.  The problem 
 with that is if you're setting margins based off surrounding content, you're 
 not going to get a layout just because your surroundings changed.

Probably a novice question but are there mechanisms or ways to trigger 
re-computing of the ruby's layout when the surrounding text has changed?

- kida

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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-28 Thread Eric Mader

On Sep 28, 2010, at 7:11 AM, David Hyatt wrote:

 The ruby element allows one or more spans of phrasing content to be marked 
 with ruby annotations.
 
 * That the text for the ruby text and ruby base are always the direct 
 child of the RenderRubyText and RenderRubyBase object.
 
 I doubt that's a valid assumption.  I assume that you can have a content 
 tree of markup underneath a RenderRubyText and a RenderRubyBase, e.g., if 
 you put in some i and some b.  Anyway, I think you could just ask for 
 the width() of the rubyText() and rubyBase() objects themselves rather than 
 drilling down into their subtrees.
 
 I couldn't figure out how to ask the RenderRubyText and RenderRubyRun 
 objects for their width. They don't support the width() method. What method 
 should I call?
 
 
 They should.  They are RenderBlocks, so they should have width() methods.  
 You may have just been getting bad results because you hooked in before the 
 width was computed.  That's why computeLogicalWidth subclassing would work 
 better for you.  Let the base class set up the margins and width, and then 
 you override.

Doh! I was trying to call width() on RenderText objects. When I called it 
directly on firstChild() and lastChild() of the RenderRubyRun, it works, but 
returns the frame width, which isn't useful for my purposes. Instead I called 
maxPrefWidth() which has the values I'm after. (only, I guess, if the ruby text 
and ruby base is a single lineā€¦)

 dave
 (hy...@apple.com)

Regards,
Eric

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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-28 Thread Yasuo Kida
Thanks. Looks like hooking findNextLineBreak is something we should try.

- kida

On 2010/09/28, at 12:56, David Hyatt wrote:

 On Sep 28, 2010, at 12:20 PM, Yasuo Kida wrote:
 
 
 On 2010/09/28, at 10:11, David Hyatt wrote:
 On Sep 27, 2010, at 3:40 PM, Eric Mader wrote:
 Are you saying that subclassing computeLogicalWidth() would still mean 
 that I'm computing the margins at the initial calculation time?
 
 You'd be computing them whenever the ruby run's layout changed.  The 
 problem with that is if you're setting margins based off surrounding 
 content, you're not going to get a layout just because your surroundings 
 changed.
 
 Probably a novice question but are there mechanisms or ways to trigger 
 re-computing of the ruby's layout when the surrounding text has changed?
 
 In this case, you really don't need to re-layout the RenderRubyRun itself.  
 You just need to possibly change its margins.  I think hooking into 
 findNextLineBreak is the easiest way to do this, since you can see your 
 surroundings and figure out what it is you'd be overlapping and how much room 
 you have on the line.
 
 dave
 (hy...@apple.com)
 

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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-27 Thread Eric Mader
A generic question: is there any in-depth documentation I can ready about block 
layout and how the various methods are supposed to be used? I've looked at the 
technical articles at http://webkit.org/coding/technical-articles.html but they 
seem to only have fairly high-level information and left me hungry for much 
more.

Specific comments below.

Regards,
Eric

On Sep 24, 2010, at 8:02 PM, David Hyatt wrote:

 It would probably be simpler to just subclass computeLogicalWidth (recently 
 renamed from calcWidth) and modify the m_marginLeft and m_marginRight 
 variables after calling the base class method.  Then you don't have to add 
 any new member variables.
 
 The big problem with building the overhang into margins at the initial 
 calculation time, though, is that you may not get a relayout when objects 
 around you change, so you won't get an opportunity to adjust your margins 
 when that happens.  Your margins are also computed before you've even know 
 what's going on the line, so it could be really tricky to have all the 
 information you need.

Are you saying that subclassing computeLogicalWidth() would still mean that I'm 
computing the margins at the initial calculation time?

 It just doesn't seem like you can deal with all the corner cases without 
 integrating right into line layout.  I don't see how else you can know if you 
 have adequate available space to actually overhang without knowing what 
 you've seen so far on the line and how much space you have left on the line.

This would require special-casing the ruby blocks in line layout code, right? I 
was trying to avoid this, hoping that I could just extend the existing ruby 
objects.

 This method makes several assumptions that I'm not 100% sure are always 
 safe:
 * That a RenderRuby object holds only 1 RenderRubyRun object.
 
 I believe you can have multiple RenderRubyRuns inside a single RenderRuby.
 
 http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-ruby-element
 
 The ruby element allows one or more spans of phrasing content to be marked 
 with ruby annotations.
 
 * That the text for the ruby text and ruby base are always the direct child 
 of the RenderRubyText and RenderRubyBase object.
 
 I doubt that's a valid assumption.  I assume that you can have a content tree 
 of markup underneath a RenderRubyText and a RenderRubyBase, e.g., if you put 
 in some i and some b.  Anyway, I think you could just ask for the width() 
 of the rubyText() and rubyBase() objects themselves rather than drilling down 
 into their subtrees.

I couldn't figure out how to ask the RenderRubyText and RenderRubyRun objects 
for their width. They don't support the width() method. What method should I 
call?


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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-22 Thread Eric Mader

On Sep 21, 2010, at 7:16 PM, Roland Steiner wrote:

 Hi Eric, 
 
 comments inline:
 
 On Wed, Sep 22, 2010 at 6:57 AM, Eric Mader ema...@apple.com wrote:
 
 On Sep 20, 2010, at 9:52 PM, Roland Steiner wrote:
 Oh vey, that's ambituous! :)  There's so many corner cases I foresee on this 
 one that I was just too happy to postpone it when we originally discussed to 
 leave out CSS3 ruby stuff from the initial implementation, which is purely 
 based off HTML5 - including supporting multiple base/text pairs within a 
 single ruby, and line-breaking within the ruby.
 Yes, it's a bit scary. ;-) I don't think I could implement the whole thing at 
 once, so I'm looking at doing a partial implementation. Maybe the first round 
 would only check to be sure that the neighboring blocks aren't ruby blocks.
 
 I would actually suggest cutting it down further and at first doing it only 
 where the neighbor is plain text - this should still catch 90% of the cases 
 where you'd want overhang and should vastly reduce the corner cases. You can 
 verify and compute this rather easily when layouting the ruby, and you'd not 
 need to worry about different glyph heights of neighboring inline elements, 
 or about replaced elements interfering. Overhang would be basically be the 
 minimum of: maximum overhang, or length of neighboring text run, or 
 available/remaining space on the line. The latter factor may also cause you 
 to need to break the ruby or move it to the next line altogether.

I'll look at this idea too. What do I need to do to find the neighboring inline 
elements?

 I'm looking at using a RenderOverflow object to implement this. Can you point 
 me at any documentation for this class, other than what's in the code? I'm 
 having some trouble sorting out what all the various rectangles used in 
 conjunction with this object represent.
 
 I have to say I'm not personally familiar with RenderOverflow, either 
 (haven't used it with ruby). Just judging from the description it stores 
 overflow rectangles for stuff that is actual content (layout overflow) and 
 stuff that is pure cosmetic rendering, such as shadows or reflections 
 (visual overflow). For ruby overhang you'd be looking at layout overflow in 
 principle (unless the overhang text also has shadows and stuff, which may add 
 to the visual overflow), AFAICT. But as I said, I'm not really an expert here.

I've been looking at RenderOverflow, and I'm beginning to suspect that it's not 
the best way to proceed. Now I'm thinking that the negative margins are the way 
to go. My guess is that I need to set the margins on either the RenderRubyRun 
object or perhaps the RenderRuby object itself. To compute the correct margins, 
it looks to me like I'll need to access the widths of the RenderRubyText and 
RenderRubyBase objects. So far, I haven't been able to work out how to do that. 
Any clues would be greatly appreciated.

 Cheers,
 
 - Roland

Regards,
Eric

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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-21 Thread Roland Steiner
Great to see someone else interested in doing ruby implementation! :)

I did the original ruby implementation, so I'm very happy to help with any
questions/problems/issues (bugs? there are not bugs!). BTW, please note that
there is another ruby patch in the review pipeline:
https://bugs.webkit.org/show_bug.cgi?id=41040 (had to modify and re-submit
this one after in-flight clashes with another patch) that might affect the
implementation.

On Tue, Sep 21, 2010 at 3:12 AM, David Hyatt hy...@apple.com wrote:

 On Sep 17, 2010, at 8:07 PM, Eric Mader wrote:

  Hi,
 
  I'm working on making the following enhancements to Ruby Text:
 
  1) Implement the behavior of ruby-overhang:auto


Oh vey, that's ambituous! :)  There's so many corner cases I foresee on this
one that I was just too happy to postpone it when we originally discussed to
leave out CSS3 ruby stuff from the initial implementation, which is purely
based off HTML5 - including supporting multiple base/text pairs within a
single ruby, and line-breaking within the ruby.



  2) implement the behavior of ruby-line-stacking:exclude-ruby


Which way do you intend to implement this? AFAICT the current consensus
seems to go towards having ruby included by default rather than excluded.



  3) Add some Mac OS specific character properties to the ruby text
 
  4) Turn off the underline when the ruby text is in a link
 
  I've looked at the code enough to know that the layout or ruby text is
 done by the normal block stacking in BlockLayout. I'm guessing that I can do
 at lest the first two tasks by changing the RenderRuby code to report a
 different width and / or height for the ruby block. Does this seem like the
 right way to do what I want?


  Assuming for the moment that it is, I have some questions:
 
  1) What methods should I subclass to report the adjusted width and
 height?
 

 I'm very hazy on the Ruby implementation.  I believe it makes an
 inline-block with two block children vertically stacked, and then it uses
 text-align:center to center the ruby base.  If so, this behavior has to be
 preserved when the ruby text is wider than the base.


Yes, that's the basic layout for a single ruby text/base pair. Note that
multiple such pairs may be contained within a single ruby element (which
is normally an inline element, unless it's floated or positioned). A ruby
may also include renderers for :before and :after content, which are outside
of the inline-blocks for base/text pairs. This is implemented in the
aforementioned patch for 41040, which also fixes some issues with
RenderRubyAsBlock and supersedes the patch for 43722).


 I think a reasonable way to implement overhang therefore would be with
 negative margins applied to the ruby run.  This way the correct layout of
 the Ruby object is preserved, and the surrounding text will just naturally
 get pushed inside the Ruby object to overlap it.

 Basically you can compare the delta in width between the base and the text
 and then apply margins to either side of the ruby run based off how you want
 to overhang.


That's also what I'd suggest. However, there are the following additional
things to consider:

.) The margin on the left side may need to be reduced because of line start
(setting it to 0), or neighboring elements that reduce how much it can
overhand (larger text or other element, a neighboring ruby element,
etc.).

.) The same goes for the right margin - however, this one is vastly more
tricky, since the following elements are probably not yet layouted.
Depending on what follows (text you can overhang, stuff that turns out you
can't overhang, the line end) you might need to increase the projected width
of the whole ruby run, which in turn might push out following elements.
There might even be extreme cases where ruby text overhangs multiple
following objects if those are very small.

You also need to be careful caching any values inside used for this inside
the ruby, because whether a ruby text may/may not overhang (or by how much)
may change dependent on changes inside _neighboring_ elements.

Also, please note that currently the size of rt is set at 60% of the base,
which is different from the standard 50%. This was chosen because it
improves readability on (low dpi) screens. If you implement ruby overhang
properly, esp. for the purposes of CJK rendering (see
http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3), you may
want/need to reconsider this, or adjust your implementation to take the
difference into consideration.

 2) If the ruby text is wider than the ruby base and I report the width of
 the base as the width of the whole block will some of the ruby text get
 clipped, or will it all still draw?
 

 It would all still draw as long as you set up overflow correctly.   You can
 look for addLayoutOverflow methods.  I think you may be able to use negative
 margins for overhang though without altering your reported width.

  3) Ruby text is only allowed to overhang the base in 

Re: [webkit-dev] Ruby Text Enhancements

2010-09-21 Thread David Hyatt

On Sep 21, 2010, at 2:52 AM, Roland Steiner wrote:

 
 
 
 We'd probably need to add a new value to that property if Ruby is supposed to 
 be skipped.
 
 Ergh Looking at it, I'm not sure that's a good proposal at all - at least 
 it has still lots to address (it doesn't address list bullets, or 
 :before/:after generated content, for one). I think that the best approach 
 for ruby would be to view the whole ruby run (i.e., base and text combined) 
 as the main object for text-decoration, and not the base and text 
 individually. That is:
 
 .) underline: line painted below the base only, over the width of base and 
 text (but excluding any overhangs!)
 .) overline: overline painted above the text, same as above - note that the 
 line width doesn't (!) change
 .) line-through: either just the base is decorated, or both base and text. I 
 can see arguments for either way, although I think painting a line-through 
 through the text may overly obscure it, since it's quite small - note that 
 the line width for the ruby text would need to be different in this case as 
 well, which in turn probably means amending the spec.
 .) blink: all blinks ;)
 
 This however means that a rule for rt would need to affect the ruby text 
 separately, independent of the decoration of the whole thing (which IMHO 
 would be a good thing anyway).

Yeah the main point I was trying to make with text-decoration is that in the 
strict mode model it's the element with text-decoration on it that draws the 
line.  So right now if you have:

a[some ruby] /a

It's the line boxes for the a element that draw a line, and it just cuts 
through the ruby no matter where the ruby happens to be (just as it might cut 
through any other objects like images that might have a different vertical 
alignment).  We have no concept of making that line skip elements or do 
something different, so it's a fair bit of work to customize the behavior.

Even more annoying is that text-decoration has two completely different code 
paths for quirks vs. strict mode.  In quirks mode, the underlines are drawn by 
the elements themselves (so e.g., you get no underlines under images in quirks 
mode), and so customizing the line drawing behavior will be easier to do in 
quirks mode.


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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-21 Thread Eric Mader

On Sep 20, 2010, at 9:52 PM, Roland Steiner wrote:

 Great to see someone else interested in doing ruby implementation! :) 
 
 I did the original ruby implementation, so I'm very happy to help with any 
 questions/problems/issues (bugs? there are not bugs!). BTW, please note that 
 there is another ruby patch in the review pipeline: 
 https://bugs.webkit.org/show_bug.cgi?id=41040 (had to modify and re-submit 
 this one after in-flight clashes with another patch) that might affect the 
 implementation.
 
 On Tue, Sep 21, 2010 at 3:12 AM, David Hyatt hy...@apple.com wrote:
 On Sep 17, 2010, at 8:07 PM, Eric Mader wrote:
 
  Hi,
 
  I'm working on making the following enhancements to Ruby Text:
 
  1) Implement the behavior of ruby-overhang:auto
 
 Oh vey, that's ambituous! :)  There's so many corner cases I foresee on this 
 one that I was just too happy to postpone it when we originally discussed to 
 leave out CSS3 ruby stuff from the initial implementation, which is purely 
 based off HTML5 - including supporting multiple base/text pairs within a 
 single ruby, and line-breaking within the ruby.

Yes, it's a bit scary. ;-) I don't think I could implement the whole thing at 
once, so I'm looking at doing a partial implementation. Maybe the first round 
would only check to be sure that the neighboring blocks aren't ruby blocks.

I'm looking at using a RenderOverflow object to implement this. Can you point 
me at any documentation for this class, other than what's in the code? I'm 
having some trouble sorting out what all the various rectangles used in 
conjunction with this object represent.

  2) implement the behavior of ruby-line-stacking:exclude-ruby
 
 Which way do you intend to implement this? AFAICT the current consensus seems 
 to go towards having ruby included by default rather than excluded.

Well, the spec. says that exclude-ruby is the default. Looking at a few example 
sites, it seems that they don't use big enough inter-line spacing to 
accommodate ruby text, so changing the exclude-ruby as the default would result 
in the ruby overlapping the previous line, which is probably worse than the 
current state where the inter-line spacing isn't uniform. (using 60% as the 
default size for ruby text probably makes this a bit worse)

As ruby implementations with the specified default implemented become more 
common, I expect that sites will be updated to use correct inter-line spacing 
and everyone will be happy. In the near-term, though, things will look worse if 
we implement the default...

  3) Add some Mac OS specific character properties to the ruby text
 
  4) Turn off the underline when the ruby text is in a link
 
  I've looked at the code enough to know that the layout or ruby text is done 
  by the normal block stacking in BlockLayout. I'm guessing that I can do at 
  lest the first two tasks by changing the RenderRuby code to report a 
  different width and / or height for the ruby block. Does this seem like the 
  right way to do what I want?
 
  Assuming for the moment that it is, I have some questions:
 
  1) What methods should I subclass to report the adjusted width and height?
 
 
 I'm very hazy on the Ruby implementation.  I believe it makes an inline-block 
 with two block children vertically stacked, and then it uses 
 text-align:center to center the ruby base.  If so, this behavior has to be 
 preserved when the ruby text is wider than the base.
 
 Yes, that's the basic layout for a single ruby text/base pair. Note that 
 multiple such pairs may be contained within a single ruby element (which is 
 normally an inline element, unless it's floated or positioned). A ruby may 
 also include renderers for :before and :after content, which are outside of 
 the inline-blocks for base/text pairs. This is implemented in the 
 aforementioned patch for 41040, which also fixes some issues with 
 RenderRubyAsBlock and supersedes the patch for 43722).
  
 I think a reasonable way to implement overhang therefore would be with 
 negative margins applied to the ruby run.  This way the correct layout of the 
 Ruby object is preserved, and the surrounding text will just naturally get 
 pushed inside the Ruby object to overlap it.
 
 Basically you can compare the delta in width between the base and the text 
 and then apply margins to either side of the ruby run based off how you want 
 to overhang.
 
 That's also what I'd suggest. However, there are the following additional 
 things to consider:

See my comments about RenderOverflow above. Is that the right way to go? Do I 
set the width of the ruby block to the width of the base text, or to the 
width of the ruby text and then give it the appropriate margins?

 
  About turning off the underline if the ruby is in a link: I've looked at 
  the styles and tried adding code to change the parts that I think relate to 
  this, but haven't found anything that makes a difference. It's also 
  occurred to me that I might be able to do this by writing 

Re: [webkit-dev] Ruby Text Enhancements

2010-09-21 Thread Roland Steiner
Hi Eric,

comments inline:

On Wed, Sep 22, 2010 at 6:57 AM, Eric Mader ema...@apple.com wrote:


 On Sep 20, 2010, at 9:52 PM, Roland Steiner wrote:

 Oh vey, that's ambituous! :)  There's so many corner cases I foresee on
 this one that I was just too happy to postpone it when we originally
 discussed to leave out CSS3 ruby stuff from the initial implementation,
 which is purely based off HTML5 - including supporting multiple base/text
 pairs within a single ruby, and line-breaking within the ruby.

 Yes, it's a bit scary. ;-) I don't think I could implement the whole thing
 at once, so I'm looking at doing a partial implementation. Maybe the first
 round would only check to be sure that the neighboring blocks aren't ruby
 blocks.


I would actually suggest cutting it down further and at first doing it only
where the neighbor is plain text - this should still catch 90% of the cases
where you'd want overhang and should vastly reduce the corner cases. You can
verify and compute this rather easily when layouting the ruby, and you'd not
need to worry about different glyph heights of neighboring inline elements,
or about replaced elements interfering. Overhang would be basically be the
minimum of: maximum overhang, or length of neighboring text run, or
available/remaining space on the line. The latter factor may also cause you
to need to break the ruby or move it to the next line altogether.


I'm looking at using a RenderOverflow object to implement this. Can you
 point me at any documentation for this class, other than what's in the code?
 I'm having some trouble sorting out what all the various rectangles used in
 conjunction with this object represent.


I have to say I'm not personally familiar with RenderOverflow, either
(haven't used it with ruby). Just judging from the description it stores
overflow rectangles for stuff that is actual content (layout overflow) and
stuff that is pure cosmetic rendering, such as shadows or reflections
(visual overflow). For ruby overhang you'd be looking at layout overflow in
principle (unless the overhang text also has shadows and stuff, which may
add to the visual overflow), AFAICT. But as I said, I'm not really an expert
here.


Cheers,

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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-20 Thread David Hyatt
On Sep 17, 2010, at 8:07 PM, Eric Mader wrote:

 Hi,
 
 I'm working on making the following enhancements to Ruby Text:
 
 1) Implement the behavior of ruby-overhang:auto
 
 2) implement the behavior of ruby-line-stacking:exclude-ruby
 
 3) Add some Mac OS specific character properties to the ruby text
 
 4) Turn off the underline when the ruby text is in a link
 
 I've looked at the code enough to know that the layout or ruby text is done 
 by the normal block stacking in BlockLayout. I'm guessing that I can do at 
 lest the first two tasks by changing the RenderRuby code to report a 
 different width and / or height for the ruby block. Does this seem like the 
 right way to do what I want?
 
 Assuming for the moment that it is, I have some questions:
 
 1) What methods should I subclass to report the adjusted width and height?
 

I'm very hazy on the Ruby implementation.  I believe it makes an inline-block 
with two block children vertically stacked, and then it uses text-align:center 
to center the ruby base.  If so, this behavior has to be preserved when the 
ruby text is wider than the base.

I think a reasonable way to implement overhang therefore would be with negative 
margins applied to the ruby run.  This way the correct layout of the Ruby 
object is preserved, and the surrounding text will just naturally get pushed 
inside the Ruby object to overlap it.

Basically you can compare the delta in width between the base and the text and 
then apply margins to either side of the ruby run based off how you want to 
overhang.

 2) If the ruby text is wider than the ruby base and I report the width of the 
 base as the width of the whole block will some of the ruby text get clipped, 
 or will it all still draw?
 

It would all still draw as long as you set up overflow correctly.   You can 
look for addLayoutOverflow methods.  I think you may be able to use negative 
margins for overhang though without altering your reported width.

 3) Ruby text is only allowed to overhang the base in some cases. To know when 
 it's OK, I'll need to examine the neighboring text. Can I always find the 
 neighboring text by walking the render tree?
 

This is going to be tricky. You basically want to walk the line box tree rather 
than the renderobject tree and then look at surrounding text.

 About turning off the underline if the ruby is in a link: I've looked at the 
 styles and tried adding code to change the parts that I think relate to this, 
 but haven't found anything that makes a difference. It's also occurred to me 
 that I might be able to do this by writing a rule in 
 WebKitWebCore/css/html.css, but I can't figure out exactly what the rule 
 would look like. I tried adding text-decoration: none to the ruby  rt 
 section, but that doesn't do it.
 
 (at first, I thought that is was probably overkill, but now I think that 
 turning text-decoration off for all ruby text is probably right.)

There is no way to do this.  The closest I see is:

http://dev.w3.org/csswg/css3-text/#text-decoration-skip

This is not implemented in WebKit yet.

We'd probably need to add a new value to that property if Ruby is supposed to 
be skipped.

dave
(hy...@apple.com)


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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-20 Thread Ryosuke Niwa
On Mon, Sep 20, 2010 at 11:12 AM, David Hyatt hy...@apple.com wrote:


 This is going to be tricky. You basically want to walk the line box tree
 rather than the renderobject tree and then look at surrounding text.

  About turning off the underline if the ruby is in a link: I've looked at
 the styles and tried adding code to change the parts that I think relate to
 this, but haven't found anything that makes a difference. It's also occurred
 to me that I might be able to do this by writing a rule in
 WebKitWebCore/css/html.css, but I can't figure out exactly what the rule
 would look like. I tried adding text-decoration: none to the ruby  rt
 section, but that doesn't do it.
 
  (at first, I thought that is was probably overkill, but now I think that
 turning text-decoration off for all ruby text is probably right.)

 There is no way to do this.  The closest I see is:

 http://dev.w3.org/csswg/css3-text/#text-decoration-skip

 This is not implemented in WebKit yet.

 We'd probably need to add a new value to that property if Ruby is supposed
 to be skipped.


Can't we ignore all text decorations when rendering a text node inside rt?

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


[webkit-dev] Ruby Text Enhancements

2010-09-17 Thread Eric Mader
Hi,

I'm working on making the following enhancements to Ruby Text:

1) Implement the behavior of ruby-overhang:auto

2) implement the behavior of ruby-line-stacking:exclude-ruby

3) Add some Mac OS specific character properties to the ruby text

4) Turn off the underline when the ruby text is in a link

I've looked at the code enough to know that the layout or ruby text is done by 
the normal block stacking in BlockLayout. I'm guessing that I can do at lest 
the first two tasks by changing the RenderRuby code to report a different width 
and / or height for the ruby block. Does this seem like the right way to do 
what I want?

Assuming for the moment that it is, I have some questions:

1) What methods should I subclass to report the adjusted width and height?

2) If the ruby text is wider than the ruby base and I report the width of the 
base as the width of the whole block will some of the ruby text get clipped, or 
will it all still draw?

3) Ruby text is only allowed to overhang the base in some cases. To know when 
it's OK, I'll need to examine the neighboring text. Can I always find the 
neighboring text by walking the render tree?

About turning off the underline if the ruby is in a link: I've looked at the 
styles and tried adding code to change the parts that I think relate to this, 
but haven't found anything that makes a difference. It's also occurred to me 
that I might be able to do this by writing a rule in 
WebKitWebCore/css/html.css, but I can't figure out exactly what the rule 
would look like. I tried adding text-decoration: none to the ruby  rt 
section, but that doesn't do it.

(at first, I thought that is was probably overkill, but now I think that 
turning text-decoration off for all ruby text is probably right.)

Regards,
Eric Mader

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