Hi! At <http://flpsed.org/hgweb/dillo_hyphen/>, you'll find a version of dillo which automatically hyphenates words, using the algorith by Frank Liang (which is also used by TeX). It is still quite messy, but works already rather stable. Some manual work is neccessary (from dillo_hyphen): mkdir /usr/local/lib/dillo/hyphenation cp test/hyph-de-1996.pat /usr/local/lib/dillo/hyphenation/de.pat cp test/hyph-en-us.pat /usr/local/lib/dillo/hyphenation/en.pat For other language, the files in the CTAN should be converted. For playing around, try this one: <http://de.wikisource.org/wiki/Spezial:Zuf%C3%A4llige_Seite> :-) Sebastian
Hi Sebastian, Sorry for the late reply, part cybernetic part human. As you noticed there was sometihng weird with the email: <quote> Delivery-date: Mon, 06 Aug 2012 20:58:14 +0200 Received: from localhost ([127.0.0.1] helo=auriga.wearlab.de) by kbs62.informatik.uni-bremen.de with esmtp (Exim 4.69) (envelope-from <dillo-dev-bounces at dillo.org>) id 1SySVI-00054b-C4; Mon, 06 Aug 2012 20:58:12 +0200 Received: from lilly.ping.de ([83.97.42.2]) by kbs62.informatik.uni-bremen.de with smtp (Exim 4.69) (envelope-from <sgeerken at dillo.org>) id 1StgCZ-0003or-8d for dillo-dev at auriga.wearlab.de; Tue, 24 Jul 2012 16:35:07 +0200 Received: (qmail 24854 invoked from network); 24 Jul 2012 14:34:46 -0000 Received: (ofmipd 188.109.158.229); 24 Jul 2012 14:34:24 -0000 Date: 24 Jul 2012 16:31:16 +0200 </quote> It took near twelve days to reach me... On Tue, Jul 24, 2012 at 04:31:16PM +0200, Sebastian Geerken wrote:
Hi!
At <http://flpsed.org/hgweb/dillo_hyphen/>, you'll find a version of dillo which automatically hyphenates words, using the algorith by Frank Liang (which is also used by TeX). It is still quite messy, but works already rather stable. Some manual work is neccessary (from dillo_hyphen):
Good work! I've downloaded/compiled and tested a bit: even in spanish! I like how it breaks paragraphs by squeezing some lines and moving words around (even without hyphenation). The hyphenating part also seems OK (I need to test more). This looks very promising and makes me look forward for the merge day! So far, dillo has served me very well for reading articles (my font/size, my colors), and now there's the extra of better line/word breaking. This will surely also be welcomed by our users. Very good. There're glitches, sure. Just in case you don't yet have a reliable test case, lwn.net has problems with screen redraw. Lefthand margin. -- Cheers Jorge.-
Hi Jorge, On Wed, Aug 22, Jorge Arellano Cid wrote:
Hi Sebastian,
Sorry for the late reply, part cybernetic part human. As you noticed there was sometihng weird with the email:
<quote> Delivery-date: Mon, 06 Aug 2012 20:58:14 +0200 Received: from localhost ([127.0.0.1] helo=auriga.wearlab.de) by kbs62.informatik.uni-bremen.de with esmtp (Exim 4.69) (envelope-from <dillo-dev-bounces at dillo.org>) id 1SySVI-00054b-C4; Mon, 06 Aug 2012 20:58:12 +0200 Received: from lilly.ping.de ([83.97.42.2]) by kbs62.informatik.uni-bremen.de with smtp (Exim 4.69) (envelope-from <sgeerken at dillo.org>) id 1StgCZ-0003or-8d for dillo-dev at auriga.wearlab.de; Tue, 24 Jul 2012 16:35:07 +0200 Received: (qmail 24854 invoked from network); 24 Jul 2012 14:34:46 -0000 Received: (ofmipd 188.109.158.229); 24 Jul 2012 14:34:24 -0000 Date: 24 Jul 2012 16:31:16 +0200 </quote>
It took near twelve days to reach me...
Yes, there were technical problems. Hopefully solved now.
On Tue, Jul 24, 2012 at 04:31:16PM +0200, Sebastian Geerken wrote:
Hi!
At <http://flpsed.org/hgweb/dillo_hyphen/>, you'll find a version of dillo which automatically hyphenates words, using the algorith by Frank Liang (which is also used by TeX). It is still quite messy, but works already rather stable. Some manual work is neccessary (from dillo_hyphen):
Good work!
Thanks. BTW, Johannes did some improvements on the actual hyphenation to reduce memory consumtion; see <http://flpsed.org/hgweb/dillo_hyphen_mem/>.
I've downloaded/compiled and tested a bit: even in spanish! I like how it breaks paragraphs by squeezing some lines and moving words around (even without hyphenation). The hyphenating part also seems OK (I need to test more).
Yes, line breaking has been improved a bit, by optimizing per line. May perhaps even be improved by applying TeX's "total fit" algorithm. As for the hyphenation, Liang's approach leads to some errors (including my surname, which is hyphenated as "Ge-er-ken", instead of "Geer-ken"), but this can be dealt with by defining exceptions.
This looks very promising and makes me look forward for the merge day! So far, dillo has served me very well for reading articles (my font/size, my colors), and now there's the extra of better line/word breaking. This will surely also be welcomed by our users. Very good.
Yes, I'd like to have this in the main repo rather soon, especially to avoid merging problems with other works.
There're glitches, sure. Just in case you don't yet have a reliable test case, lwn.net has problems with screen redraw. Lefthand margin.
I know of a problem relating tables, but somehow was not able to construct a test case. I found nothing special about lwn.net, but I'll ask you to test again after the fix. Sebastian
On Wed, Aug 22, Jorge Arellano Cid wrote:
There're glitches, sure. Just in case you don't yet have a reliable test case, lwn.net has problems with screen redraw. Lefthand margin.
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again. Sebastian
On Tue, Sep 04, 2012 at 02:36:29PM +0200, Sebastian Geerken wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
Nice! lwn.net and wikipedia look good for me now, but the text on the splash screen seems a bit squeezed. Johannes
Just pushed some more changes; should be complete now. Please test thoroughly.
Nice! lwn.net and wikipedia look good for me now, but the text on the splash screen seems a bit squeezed.
I see no difference to the current main repository. I investigated this already some days ago, and found out that paragraphs are handled differenty. Defining a margin for paragraphs works, OTOH. So this is no reason to delay merging. :-) Sebastian
On Tue, Sep 04, Johannes Hofmann wrote:
On Tue, Sep 04, 2012 at 02:36:29PM +0200, Sebastian Geerken wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
Nice! lwn.net and wikipedia look good for me now, but the text on the splash screen seems a bit squeezed.
Now I see what you mean: the too narrow text blocks. Fixed now. Sebastian
On Tue, Sep 04, 2012 at 06:46:30PM +0200, Sebastian Geerken wrote:
On Tue, Sep 04, Johannes Hofmann wrote:
On Tue, Sep 04, 2012 at 02:36:29PM +0200, Sebastian Geerken wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
Nice! lwn.net and wikipedia look good for me now, but the text on the splash screen seems a bit squeezed.
Now I see what you mean: the too narrow text blocks. Fixed now.
Cool, works for me as well now! Johannes
On Tue, Sep 04, 2012 at 08:55:19PM +0200, Johannes Hofmann wrote:
On Tue, Sep 04, 2012 at 06:46:30PM +0200, Sebastian Geerken wrote:
On Tue, Sep 04, Johannes Hofmann wrote:
On Tue, Sep 04, 2012 at 02:36:29PM +0200, Sebastian Geerken wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
Several sites I visit don't trigger hyphenation because they lack the "lang" attribute. I'm experimenting with a very simple language guess routine, to get an idea of how it could help in this regard. @Johannes, This function samples text from the parser, and it may fall anywhere on the CSS tree. How can I set it for the HTML element so it is inherited from there? I've tried: html->styleEngine->setNonCssHint( PROPERTY_X_LANG, CSS_TYPE_STRING, html->lang); which seems to set it for the current element only. and html->styleEngine->restyle (); with no good result. TIA. -- Cheers Jorge.-
Hi Jorge, On Wed, Sep 05, 2012 at 02:30:32PM -0300, Jorge Arellano Cid wrote:
On Tue, Sep 04, 2012 at 08:55:19PM +0200, Johannes Hofmann wrote:
On Tue, Sep 04, 2012 at 06:46:30PM +0200, Sebastian Geerken wrote:
On Tue, Sep 04, Johannes Hofmann wrote:
On Tue, Sep 04, 2012 at 02:36:29PM +0200, Sebastian Geerken wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
Several sites I visit don't trigger hyphenation because they lack the "lang" attribute. I'm experimenting with a very simple language guess routine, to get an idea of how it could help in this regard.
@Johannes, This function samples text from the parser, and it may fall anywhere on the CSS tree. How can I set it for the HTML element so it is inherited from there?
Fancy! Unfortunately you probabely only know the language of an element, after you've seen text from it. That's too late. You would need to do the setNonCssHint() before the first call to getStyle() on that element. So basically you would need to somehow remember the language for each element and then reload and set the appropriate language for the element - but I agree that that's not really elegant.
I've tried:
html->styleEngine->setNonCssHint( PROPERTY_X_LANG, CSS_TYPE_STRING, html->lang);
which seems to set it for the current element only.
and
html->styleEngine->restyle ();
with no good result.
Yeah, I fear restyle() does not what you need here. For now we could simply expose x-lang to the css parser, so you can at least set a reasonable default (e.g. body { x-lang:"en" } )in your ~/.dillo/style.css (see attached patch against dillo_hyphenation). Cheers, Johannes
Hi Dillo developers and Sebastian. On Wed, Sep 05, 2012 at 02:30:32PM -0300, Jorge Arellano Cid wrote:
Several sites I visit don't trigger hyphenation because they lack the "lang" attribute. I'm experimenting with a very simple language guess routine, to get an idea of how it could help in this regard.
Is the xml:lang attribute (in the <html> tag) currently supported? Best, Alexander
On Thu, Sep 06, Alexander Voigt wrote:
Hi Dillo developers and Sebastian.
On Wed, Sep 05, 2012 at 02:30:32PM -0300, Jorge Arellano Cid wrote:
Several sites I visit don't trigger hyphenation because they lack the "lang" attribute. I'm experimenting with a very simple language guess routine, to get an idea of how it could help in this regard.
Is the xml:lang attribute (in the <html> tag) currently supported?
No, not yet. BTW: I haven't understood whether "xml:" is a normal namespace prefix (for which namespace?) or is specialy reserved (and may so not be used as namespace prefix). In the latter case, support would be rather simple. Sebastian
Hi Sebastian. On Mon, Sep 10, 2012 at 08:45:22PM +0200, Sebastian Geerken wrote:
No, not yet. BTW: I haven't understood whether "xml:" is a normal namespace prefix (for which namespace?) or is specialy reserved (and may so not be used as namespace prefix). In the latter case, support would be rather simple.
As written in [1], the "xml:" prefix is bound to the namespace http://www.w3.org/XML/1998/namespace , which is reseved for the W3C. This means that the nobody, except the W3C, can reuse this prefix for their own namespace. So, as long as the meaning of "xml:lang" does not change (which is very unlikely), it can be interpreted in the same way as the "lang" attribute. [1] http://www.w3.org/XML/1998/namespace Best, Alex
On Thu, Sep 13, Alexander Voigt wrote:
On Mon, Sep 10, 2012 at 08:45:22PM +0200, Sebastian Geerken wrote:
No, not yet. BTW: I haven't understood whether "xml:" is a normal namespace prefix (for which namespace?) or is specialy reserved (and may so not be used as namespace prefix). In the latter case, support would be rather simple.
As written in [1], the "xml:" prefix is bound to the namespace http://www.w3.org/XML/1998/namespace , which is reseved for the W3C. This means that the nobody, except the W3C, can reuse this prefix for their own namespace.
So, as long as the meaning of "xml:lang" does not change (which is very unlikely), it can be interpreted in the same way as the "lang" attribute.
So, this simple patch (or similar): ---------------------------------------------------------------------- diff -r d0a8d2a5ede3 src/html.cc --- a/src/html.cc Thu Sep 13 12:35:54 2012 +0200 +++ b/src/html.cc Fri Sep 14 12:35:38 2012 +0200 @@ -3448,6 +3448,15 @@ html->styleEngine->setNonCssHint(PROPERTY_X_LANG, CSS_TYPE_STRING, attrbuf); } + + if (tagsize >= 14) { /* TODO prefs.hyphenate? */ + /* length of "<t xml:lang=i>" */ + attrbuf = Html_get_attr2(html, tag, tagsize, "xml:lang", + HTML_LeftTrim | HTML_RightTrim); + if (attrbuf) + html->styleEngine->setNonCssHint(PROPERTY_X_LANG, CSS_TYPE_STRING, + attrbuf); + } } static void Html_display_block(DilloHtml *html) ---------------------------------------------------------------------- would work, without bothering about XML namespaces (in the near future). What do the other developers think? Sebastian
Hi Sebastian, On Fri, Sep 14, 2012 at 12:38:46PM +0200, Sebastian Geerken wrote:
On Thu, Sep 13, Alexander Voigt wrote:
On Mon, Sep 10, 2012 at 08:45:22PM +0200, Sebastian Geerken wrote:
No, not yet. BTW: I haven't understood whether "xml:" is a normal namespace prefix (for which namespace?) or is specialy reserved (and may so not be used as namespace prefix). In the latter case, support would be rather simple.
As written in [1], the "xml:" prefix is bound to the namespace http://www.w3.org/XML/1998/namespace , which is reseved for the W3C. This means that the nobody, except the W3C, can reuse this prefix for their own namespace.
So, as long as the meaning of "xml:lang" does not change (which is very unlikely), it can be interpreted in the same way as the "lang" attribute.
So, this simple patch (or similar):
---------------------------------------------------------------------- diff -r d0a8d2a5ede3 src/html.cc --- a/src/html.cc Thu Sep 13 12:35:54 2012 +0200 +++ b/src/html.cc Fri Sep 14 12:35:38 2012 +0200 @@ -3448,6 +3448,15 @@ html->styleEngine->setNonCssHint(PROPERTY_X_LANG, CSS_TYPE_STRING, attrbuf); } + + if (tagsize >= 14) { /* TODO prefs.hyphenate? */ + /* length of "<t xml:lang=i>" */ + attrbuf = Html_get_attr2(html, tag, tagsize, "xml:lang", + HTML_LeftTrim | HTML_RightTrim); + if (attrbuf) + html->styleEngine->setNonCssHint(PROPERTY_X_LANG, CSS_TYPE_STRING, + attrbuf); + } }
static void Html_display_block(DilloHtml *html) ----------------------------------------------------------------------
would work, without bothering about XML namespaces (in the near future). What do the other developers think?
Yes, it looks OK to me. I'd go with the attached patch (a bit more explicit, +comments) Feel free to commit. -- Cheers Jorge.-
On Wed, Sep 26, Jorge Arellano Cid wrote:
On Fri, Sep 14, 2012 at 12:38:46PM +0200, Sebastian Geerken wrote:
On Thu, Sep 13, Alexander Voigt wrote:
On Mon, Sep 10, 2012 at 08:45:22PM +0200, Sebastian Geerken wrote:
No, not yet. BTW: I haven't understood whether "xml:" is a normal namespace prefix (for which namespace?) or is specialy reserved (and may so not be used as namespace prefix). In the latter case, support would be rather simple.
As written in [1], the "xml:" prefix is bound to the namespace http://www.w3.org/XML/1998/namespace , which is reseved for the W3C. This means that the nobody, except the W3C, can reuse this prefix for their own namespace.
So, as long as the meaning of "xml:lang" does not change (which is very unlikely), it can be interpreted in the same way as the "lang" attribute.
So, this simple patch (or similar):
---------------------------------------------------------------------- [...] ----------------------------------------------------------------------
would work, without bothering about XML namespaces (in the near future). What do the other developers think?
Yes, it looks OK to me.
I'd go with the attached patch (a bit more explicit, +comments)
Feel free to commit.
Done. Sebastian
Sebastian wrote:
Just pushed some more changes; should be complete now. Please test thoroughly.
On http://www.dillo.org/stats/ , it breaks between the month and year.
On Tue, Sep 04, corvid wrote:
On http://www.dillo.org/stats/ , it breaks between the month and year.
Fixed. Look at the change: it's simple. Unlike before, breaks are also prohibited for "white-space: pre-wrap"; this is how I interpret the CSS spec. Sebastian
Sebastian wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
I'm noticing occasional overlapping of text with alt text (example from linuxquestions.org: http://www.dillo.org/test/alt_text.jpg ), and, when I load those images, I see that there's some clipping ( http://www.dillo.org/test/img_clipped.jpg ).
On Tue, Sep 04, corvid wrote:
Sebastian wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
I'm noticing occasional overlapping of text with alt text (example from linuxquestions.org: http://www.dillo.org/test/alt_text.jpg ), and, when I load those images, I see that there's some clipping ( http://www.dillo.org/test/img_clipped.jpg ).
Can you reproduce this with the latest version? It may have been fixed with the last change. Sebastian
Sebastian wrote:
On Tue, Sep 04, corvid wrote:
Sebastian wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
I'm noticing occasional overlapping of text with alt text (example from linuxquestions.org: http://www.dillo.org/test/alt_text.jpg ), and, when I load those images, I see that there's some clipping ( http://www.dillo.org/test/img_clipped.jpg ).
Can you reproduce this with the latest version? It may have been fixed with the last change.
I can still reproduce it.
On Tue, Sep 04, corvid wrote:
Sebastian wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
I'm noticing occasional overlapping of text with alt text (example from linuxquestions.org: http://www.dillo.org/test/alt_text.jpg ), and, when I load those images, I see that there's some clipping ( http://www.dillo.org/test/img_clipped.jpg ).
I've just pushed some changes, which will result in a broken line, which is OK. With no images shown, the column is somehow still too narrow, but the current release of dillo renders it too large. Sebastian
On Tue, Sep 04, 2012 at 02:36:29PM +0200, Sebastian Geerken wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
For me it crashes on e.g. focus.de after resizing the window or clicking a link. The stack is pretty long: Program terminated with signal 11, Segmentation fault. #0 0x0809adb6 in dw::Textblock::rewrap (this=0x2aca07f0) at textblock_linebreaking.cc:901 901 if (word->content.type == core::Content::WIDGET) { (gdb) bt #0 0x0809adb6 in dw::Textblock::rewrap (this=0x2aca07f0) at textblock_linebreaking.cc:901 #1 0x080975e7 in dw::Textblock::sizeRequestImpl (this=0x2aca07f0, requisition=0x287525f0) at textblock.cc:140 #2 0x080b6d3f in dw::core::Widget::sizeRequest (this=0x2aca07f0, requisition=0x287525f0) at widget.cc:176 #3 0x080949e1 in dw::Textblock::calcWidgetSize (this=0x2aca1930, widget=0x2aca07f0, size=0x287525f0) at textblock.cc:772 #4 0x0809ae04 in dw::Textblock::rewrap (this=0x2aca1930) at textblock_linebreaking.cc:897 #5 0x080975e7 in dw::Textblock::sizeRequestImpl (this=0x2aca1930, requisition=0x28cd6570) at textblock.cc:140 #6 0x080b6d3f in dw::core::Widget::sizeRequest (this=0x2aca1930, requisition=0x28cd6570) at widget.cc:176 #7 0x080949e1 in dw::Textblock::calcWidgetSize (this=0x2aca4030, widget=0x2aca1930, size=0x28cd6570) at textblock.cc:772 #8 0x0809ae04 in dw::Textblock::rewrap (this=0x2aca4030) at textblock_linebreaking.cc:897 #9 0x080975e7 in dw::Textblock::sizeRequestImpl (this=0x2aca4030, requisition=0x2aca3bb0) at textblock.cc:140 #10 0x080b6d3f in dw::core::Widget::sizeRequest (this=0x2aca4030, requisition=0x2aca3bb0) at widget.cc:176 #11 0x080949e1 in dw::Textblock::calcWidgetSize (this=0x2aca4330, widget=0x2aca4030, size=0x2aca3bb0) at textblock.cc:772 #12 0x0809ae04 in dw::Textblock::rewrap (this=0x2aca4330) at textblock_linebreaking.cc:897 #13 0x080975e7 in dw::Textblock::sizeRequestImpl (this=0x2aca4330, requisition=0x2aca3df0) at textblock.cc:140 #14 0x080b6d3f in dw::core::Widget::sizeRequest (this=0x2aca4330, requisition=0x2aca3df0) at widget.cc:176 #15 0x080949e1 in dw::Textblock::calcWidgetSize (this=0x2aca41b0, widget=0x2aca4330, size=0x2aca3df0) at textblock.cc:772 #16 0x0809ae04 in dw::Textblock::rewrap (this=0x2aca41b0) at textblock_linebreaking.cc:897 #17 0x080975e7 in dw::Textblock::sizeRequestImpl (this=0x2aca41b0, requisition=0x287d10f8) at textblock.cc:140 #18 0x080b6d3f in dw::core::Widget::sizeRequest (this=0x2aca41b0, requisition=0x287d10f8) at widget.cc:176 ... Any ideas? Johannes
On Wed, Sep 05, Johannes Hofmann wrote:
On Tue, Sep 04, 2012 at 02:36:29PM +0200, Sebastian Geerken wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
For me it crashes on e.g. focus.de after resizing the window or clicking a link. The stack is pretty long: ...
Still? I found test/anchrors.html as a test case (crashing when the window is resized), but this is now fix. Please test again. Sebastian
On Thu, Sep 06, 2012 at 10:22:15AM +0200, Sebastian Geerken wrote:
On Wed, Sep 05, Johannes Hofmann wrote:
On Tue, Sep 04, 2012 at 02:36:29PM +0200, Sebastian Geerken wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
For me it crashes on e.g. focus.de after resizing the window or clicking a link. The stack is pretty long: ...
Still? I found test/anchrors.html as a test case (crashing when the window is resized), but this is now fix. Please test again.
Works fine now! Very nice. Thanks, Johannes
On Thu, Sep 06, 2012 at 07:51:08PM +0200, Johannes Hofmann wrote:
On Thu, Sep 06, 2012 at 10:22:15AM +0200, Sebastian Geerken wrote:
On Wed, Sep 05, Johannes Hofmann wrote:
On Tue, Sep 04, 2012 at 02:36:29PM +0200, Sebastian Geerken wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
For me it crashes on e.g. focus.de after resizing the window or clicking a link. The stack is pretty long: ...
Still? I found test/anchrors.html as a test case (crashing when the window is resized), but this is now fix. Please test again.
Works fine now! Very nice.
I found another example, where it still crashes: http://www.x.org/archive/X11R7.5/doc/man/man3/Xft.3.html It crashes here if I make the window smaller.
On Thu, Sep 06, 2012 at 08:46:04PM +0200, Johannes Hofmann wrote:
On Thu, Sep 06, 2012 at 07:51:08PM +0200, Johannes Hofmann wrote:
On Thu, Sep 06, 2012 at 10:22:15AM +0200, Sebastian Geerken wrote:
On Wed, Sep 05, Johannes Hofmann wrote:
On Tue, Sep 04, 2012 at 02:36:29PM +0200, Sebastian Geerken wrote:
I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again.
Just pushed some more changes; should be complete now. Please test thoroughly.
For me it crashes on e.g. focus.de after resizing the window or clicking a link. The stack is pretty long: ...
Still? I found test/anchrors.html as a test case (crashing when the window is resized), but this is now fix. Please test again.
Works fine now! Very nice.
I found another example, where it still crashes: http://www.x.org/archive/X11R7.5/doc/man/man3/Xft.3.html
It crashes here if I make the window smaller.
Update: The following patch fixes the crash for me: diff -r 8671009fbcaf dw/textblock_linebreaking.cc --- a/dw/textblock_linebreaking.cc Thu Sep 06 18:09:03 2012 +0200 +++ b/dw/textblock_linebreaking.cc Sun Sep 09 22:31:01 2012 +0200 @@ -588,6 +588,9 @@ wordIndexEnd += n; PRINTF ("[%p] -> new searchUntil = %d ...\n", this, searchUntil); lineAdded = false; + // update word pointer as hyphenateWord() can trigger a + // reorganization of the words structure + word = words->getRef (wordIndex); } PRINTF ("[%p] accumulating again from %d to %d\n",
On Sun, Sep 09, Johannes Hofmann wrote:
On Thu, Sep 06, 2012 at 08:46:04PM +0200, Johannes Hofmann wrote:
I found another example, where it still crashes: http://www.x.org/archive/X11R7.5/doc/man/man3/Xft.3.html
It crashes here if I make the window smaller.
Update: The following patch fixes the crash for me: [...]
I could not reproduce the bug, but the patch is correct and neccessary, so I've committed it. Sebastian
I was looking at the src for http://distrowatch.com , and the source page is very wide -- wider than any lines, so far as I could see.
On Mon, Sep 10, 2012 at 09:00:03PM +0000, corvid wrote:
I was looking at the src for http://distrowatch.com , and the source page is very wide -- wider than any lines, so far as I could see.
I think there is a problem with the white-space: property handling. Here is a test case: nowrap: <div style="white-space: nowrap"> hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo </div> pre: <div style="white-space: pre"> hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo </div> pre-wrap: <div style="white-space: pre-wrap"> hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo </div> pre-line: <div style="white-space: pre-line"> hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo hallo dillo </div> I can have look at this. Cheers, Johannes
On Mon, Sep 10, corvid wrote:
I was looking at the src for http://distrowatch.com , and the source page is very wide -- wider than any lines, so far as I could see.
There is one line, which is very long (number 54), but the current release breaks this line into multiple ones. Can someone provide details about the vsource plugin? Sebastian
Sebastian wrote:
On Mon, Sep 10, corvid wrote:
I was looking at the src for http://distrowatch.com , and the source page is very wide -- wider than any lines, so far as I could see.
There is one line, which is very long (number 54), but the current release breaks this line into multiple ones. Can someone provide details about the vsource plugin?
The vsource page has <style type="text/css">PRE {white-space: pre-wrap} and the css2 spec says "If 'white-space' is set to 'pre' or 'pre-wrap', any sequence of spaces (U+0020) unbroken by an element boundary is treated as a sequence of non-breaking spaces. However, for 'pre-wrap', a line breaking opportunity exists at the end of the sequence."
On Wed, Nov 07, corvid wrote:
Sebastian wrote:
On Mon, Sep 10, corvid wrote:
I was looking at the src for http://distrowatch.com , and the source page is very wide -- wider than any lines, so far as I could see.
There is one line, which is very long (number 54), but the current release breaks this line into multiple ones. Can someone provide details about the vsource plugin?
The vsource page has <style type="text/css">PRE {white-space: pre-wrap} and the css2 spec says "If 'white-space' is set to 'pre' or 'pre-wrap', any sequence of spaces (U+0020) unbroken by an element boundary is treated as a sequence of non-breaking spaces. However, for 'pre-wrap', a line breaking opportunity exists at the end of the sequence."
So "pre-wrap" can be broken. Fixed. Sebastian
The borders on the "Search results" and "Nutrient values" boxes are overlapping on http://www.bitelog.com/mega-food-search.htm?q=masa
I wrote:
The borders on the "Search results" and "Nutrient values" boxes are overlapping on http://www.bitelog.com/mega-food-search.htm?q=masa
I got around to trimming it down to a small example of brokenness (attached). Interestingly, the "10000" protrudes out of the left end of the table on firefox, which suggests there might be something wrong about this page in a way that I'm not immediately grasping. (Although it's nicer to think that firefox is buggy.)
On Wed, Nov 28, corvid wrote:
I wrote:
The borders on the "Search results" and "Nutrient values" boxes are overlapping on http://www.bitelog.com/mega-food-search.htm?q=masa
I got around to trimming it down to a small example of brokenness (attached).
Thanks, this helped a lot. The bug is fixed now.
Interestingly, the "10000" protrudes out of the left end of the table on firefox, which suggests there might be something wrong about this page in a way that I'm not immediately grasping. (Although it's nicer to think that firefox is buggy.)
It seems that firefox is reserving a fixed space for list bullets/numbers, while dillo calculates the necessary space. Sebastian
With tip, I can't see the option in: <div> <select> <option value="100">object</option> </select> </div> With a dillo that I have around from right before the hyphenation merge, the option appears.
participants (6)
-
corvid＠lavabit.com -
Hole.destructor＠gmx.de -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
johannes.hofmann＠gmx.de
-
sgeerken＠dillo.org