- Dillo-dev - lists.mailman3.com

auto/abs sizes in image.cc, auto/abs/per in textblock.cc

by corvid＠lavabit.com

At http://naturalhistory.museumwales.ac.uk/sharpshooters/ two of the image tags specify a size for one dimension, giving it as 100%. When one dimension is auto and the other is percentage, it doesn't scale properly. I see that calculation using percentage has to be in textblock because it uses availWidth or availHeight, so... is there a deep need to keep the auto/abs case in Image's sizeRequestImpl instead of Textblock's calcWidgetSize? I was just playing with adding all of the cases to calcWidgetSize and it looked like it was working except that an unloaded image with, e.g., height=100% alt=whatever would end up ridiculously wide because height_of_page / height_of_alt_text * width_of_alt_text is a large number.

Oct. 7, 2009

textarea multiline input bug

by corvid＠lavabit.com

Dennis wrote: > In textareas (multiline form input), say for example: > > http://translate.google.ca/translate_t > > ... if I first enter the following line into the textarea: > > yo soy anarco-capitalista > > ... and after submitting it, I edit it (the previous contents are > retained -- although I suspect internally there might be something > broken -- not sure where it breaks exactly.), by inserting a newline at > the very beginning (pressing enter), then backspacing (removing the > newline) to make it appear exactly the same, then resubmitting the > form, strange stuff happens. > > (I remember earlier posting experiences some of my lines getting > duplicated, and other strange stuff. I think it only happens when I > edit stuff at the beginning.) You have found a FLTK bug. I think in the beginning of TextBuffer::text(), where it goes if (!gapstart_ && length_) { buf_[length_+gapend_] = 0; return buf_+gapstart_; } they want if (!gapstart_ && length_) { buf_[length_+gapend_] = 0; return buf_+gapend_; }

Oct. 2, 2009

textarea multiline input bug

by dennisn＠dennisn.dyndns.org

In textareas (multiline form input), say for example: http://translate.google.ca/translate_t ... if I first enter the following line into the textarea: yo soy anarco-capitalista ... and after submitting it, I edit it (the previous contents are retained -- although I suspect internally there might be something broken -- not sure where it breaks exactly.), by inserting a newline at the very beginning (pressing enter), then backspacing (removing the newline) to make it appear exactly the same, then resubmitting the form, strange stuff happens. (I remember earlier posting experiences some of my lines getting duplicated, and other strange stuff. I think it only happens when I edit stuff at the beginning.)

Oct. 2, 2009

experimental patch: zero width space (Thai, Lao, Cambodian...)

by corvid＠lavabit.com

Johannes wrote: > On Tue, Sep 29, 2009 at 07:30:22PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote: > > > > PS I did just start trying to move the ideographic test to dw, > > > > but I got stuck when I realized that I can't exactly call fltk's > > > > utf8decode() directly in Textblock, and am not excited by the > > > > idea of calling it through Layout. > > > > > > > > > > I think we could make the utf8 methods in fltkplatform.cc static > > > members. > > > > In this case, that would save us... carrying along a this > > pointer that we weren't using? Does it save an indirection? > > > > (in any case, maybe I should static-ize all of our current > > fltkplatform functions that just call fltk functions) > > Wait. Making them static is not a good idea. Currently we could > have different platforms in a single process and the right methods > would be called. > Are you concerned about speed or readability? It sounded slow to go through layout, but then we do our share of nextGlyph, textWidth, etc, and haven't died from it. Maybe it's time to get gprof out again anyway.

Sept. 30, 2009

experimental patch: zero width space (Thai, Lao, Cambodian...)

by Johannes.Hofmann＠gmx.de

On Tue, Sep 29, 2009 at 07:30:22PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote: > > > I just learned that some languages don't use spaces but can only > > > break in certain places, and that they tend to insert > > > Zero Width Space to make life easier for software that > > > doesn't know the complex rules. > > > > > > So here's a quick little patch for them: > > > http://www.dillo.org/test/zero_width_space.patch > > > > Looks good to me, but do we really need to add a space? > > Wouldn't it be enough to just start a new word? > > At least dw-example seems to wrap words with > > textblock->addSpace(wordStyle); commented out. > > I was thinking that it would be good to remember that it's > there so that the iterator could be made to do the right > thing for copying and pasting text, but maybe that's too > much of a picky corner case akin to soft hyphens. > (And maybe stripping them out would make life simpler for > findtext anyway.) Hm, don't know what's better... > > > > > > > > > > PS I did just start trying to move the ideographic test to dw, > > > but I got stuck when I realized that I can't exactly call fltk's > > > utf8decode() directly in Textblock, and am not excited by the > > > idea of calling it through Layout. > > > > > > > I think we could make the utf8 methods in fltkplatform.cc static > > members. > > In this case, that would save us... carrying along a this > pointer that we weren't using? Does it save an indirection? > > (in any case, maybe I should static-ize all of our current > fltkplatform functions that just call fltk functions) Wait. Making them static is not a good idea. Currently we could have different platforms in a single process and the right methods would be called. Are you concerned about speed or readability? Cheers, Johannes

Sept. 29, 2009

experimental patch: zero width space (Thai, Lao, Cambodian...)

by corvid＠lavabit.com

Johannes wrote: > On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote: > > I just learned that some languages don't use spaces but can only > > break in certain places, and that they tend to insert > > Zero Width Space to make life easier for software that > > doesn't know the complex rules. > > > > So here's a quick little patch for them: > > http://www.dillo.org/test/zero_width_space.patch > > Looks good to me, but do we really need to add a space? > Wouldn't it be enough to just start a new word? > At least dw-example seems to wrap words with > textblock->addSpace(wordStyle); commented out. I was thinking that it would be good to remember that it's there so that the iterator could be made to do the right thing for copying and pasting text, but maybe that's too much of a picky corner case akin to soft hyphens. (And maybe stripping them out would make life simpler for findtext anyway.) > > > > > > PS I did just start trying to move the ideographic test to dw, > > but I got stuck when I realized that I can't exactly call fltk's > > utf8decode() directly in Textblock, and am not excited by the > > idea of calling it through Layout. > > > > I think we could make the utf8 methods in fltkplatform.cc static > members. In this case, that would save us... carrying along a this pointer that we weren't using? Does it save an indirection? (in any case, maybe I should static-ize all of our current fltkplatform functions that just call fltk functions)

Sept. 29, 2009

What's the status of USE_TABLES?

by jcid＠dillo.org

On Tue, Sep 29, 2009 at 07:30:47PM +0100, Jeremy Henty wrote: > On Tue, Sep 29, 2009 at 12:53:44PM -0400, Jorge Arellano Cid wrote: > > On Mon, Sep 28, 2009 at 08:01:19PM +0100, Jeremy Henty wrote: > > > > > > ... is USE_TABLES obsolete or not? ... > > > > OK remove it. > > Patch attached. Committed. -- Cheers Jorge.-

Sept. 29, 2009

What's the status of USE_TABLES?

by onepoint＠starurchin.org

On Tue, Sep 29, 2009 at 12:53:44PM -0400, Jorge Arellano Cid wrote: > On Mon, Sep 28, 2009 at 08:01:19PM +0100, Jeremy Henty wrote: > > > > ... is USE_TABLES obsolete or not? ... > > OK remove it. Patch attached. Jeremy Henty

Sept. 29, 2009

experimental patch: zero width space (Thai, Lao, Cambodian...)

by Johannes.Hofmann＠gmx.de

On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote: > I just learned that some languages don't use spaces but can only > break in certain places, and that they tend to insert > Zero Width Space to make life easier for software that > doesn't know the complex rules. > > So here's a quick little patch for them: > http://www.dillo.org/test/zero_width_space.patch Looks good to me, but do we really need to add a space? Wouldn't it be enough to just start a new word? At least dw-example seems to wrap words with textblock->addSpace(wordStyle); commented out. > > > PS I did just start trying to move the ideographic test to dw, > but I got stuck when I realized that I can't exactly call fltk's > utf8decode() directly in Textblock, and am not excited by the > idea of calling it through Layout. > I think we could make the utf8 methods in fltkplatform.cc static members. Cheers, Johannes

Sept. 29, 2009

What's the status of USE_TABLES?

by jcid＠dillo.org

On Mon, Sep 28, 2009 at 08:01:19PM +0100, Jeremy Henty wrote: > > This came up as an aside to the meta refresh discussion in another > thread: is USE_TABLES obsolete or not? If it is, we should remove it, > if not, it should be hooked to a configure flag. I'll submit a patch > as soon as someone tells me which way to go. OK remove it. I hesitated because it was useful long ago. OTOH it's broken and a custom CSS template seems a better solution for the problem it tried to solve. -- Cheers Jorge.-

Sept. 29, 2009