Re: HTML rendering

[Eli Zaretskii]

> Date: Mon, 06 Jul 2015 13:37:19 +0900
> From: Katsumi Yamaoka <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> 
> > But then how to explain that only 1 character was overflowing the line
> > length?  If your explanation were correct, you'd have half the
> > characters spilled to the next line.
> 
> If you meant one Japanese character overflowing, simply move it
> to the next line like the fill functions do, except for KINSOKU
> characters.

No, that's not what I meant.  I meant that the problem cannot be
incorrect accounting for wide characters, because then there's no way
we can explain why lines are always exactly one character too long.

Anyway, going back to what you said before:

> The functions that fill text lines are shr-fill-line,
> shr-vertical-motion, and so forth.  I think the cause filling
> Japanese text fails is that shr-vertical-motion uses
> 
> (frame-char-width)
> 
> to decide the fill position.  It returns 8 in my case, however
> the width of Japanses characters is 16.

No, I don't think this is the root cause of the problem.
shr-vertical-motion calls vertical-motion, which internally does all
its calculations in pixels, by converting the columns into pixels
using the frame's canonical character width.  So dividing by the value
returned by frame-char-width is exactly the right thing.

> FYI:
> ・Japanese text doesn't use space to separate words normally.
> ・Japanese text may be folded even at the middle of a word.
> ・KINSOKU processing is required.  cf. international/kinsoku.el

I think this is the root cause of the problem: when the line is too
long, shr-fill-line attempts to find a place to break it, by looking
for whitespace characters.  But in your example, there are no such
characters, so shr simply punts and does nothing.

Lars, why don't you use functions in fill.el to do that?  They already
know about kinsoku, so should DTRT without you having to reinvent the
wheel.  Is something missing in fill.el to support this use case?