- Dillo-dev - lists.mailman3.com

dillo development
by jcid＠dillo.org Sept. 28, 2016

Sept. 28, 2016

Hi there, Please expect very good news in the next months... (there's very nice code developing in the labs now). Just that, stay tuned. -- Cheers Jorge.-

2 1

Site doesn't render - just HTML code
by nick＠linicks.net Sept. 21, 2016

Sept. 21, 2016

Only me again :) Firefox, links and lynx render this page OK, but Dillo just shows the HTML code: http://www.afrowsoft.co.uk ? Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

2 2

Startup time of the latest dev versions.
by johnfound＠asm32.info Sept. 19, 2016

Sept. 19, 2016

I am using Dillo as a help viewer of my IDE, because it has really short startup times and pressing F1 I get instant access to the documentation. Recently I tried to compile and use the recent development versions from the hg repository, because of the recent changes in the rendering and the general improvements in the browser. But unfortunately, the startup time seems to be increased and now I have to wait 2..3 seconds for browser to start and to show my help files. Is such slow startup time side effect of some changes that will be fixed some day, or it is kind of compromise, because of other improvements and this way will persists in the project from now on? Or (what is pretty possible) I messed something with the compilation? -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

5 9

Entry in cookiesrc locks Dillo up
by nick＠linicks.net Sept. 16, 2016

Sept. 16, 2016

Hi All, I frequent a Slackware Pi forum, and decided to get Dillo to remember my log-in details with cookies. The URL is (in my bookmarks file): http://forum.fatdog.eu/viewforum.php?f=30 If I add: forum.fatdog.eu ACCEPT in my cookiesrc file, then start Dillo, click on the above said link in bookmarks, Dillo locks up and the only way out is to kill it from the command line. Any ideas on this? Or am I being stupid? Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

1 2

Get Dillo to honour target=_blank
by nick＠linicks.net Aug. 29, 2016

Aug. 29, 2016

Hi all, How easy (or hard) would it be to get Dillo to honour the URL/FORM directive 'target="_blank" to get URL/CGI data returned in a new tab? I ahve looked at the code, seeing as Dillo already has tabs, but I just don't get C++ classes and stuff, and wouldn't know where to begin. The reason for asking this is if one has a form with a lot of data that needs processing, once submitted the data gets returned to the parent page... if there is a mistake, then you need to go back to the form, and as Dillo doesn't keep the previous page data, you have to fill it all in again. By diverting the output to a new tab, the previous parent window remains the same, ready for editing and processing again. Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

3 6

Underscores not drawn in pre with background color
by Hole.destructor＠gmx.de Aug. 17, 2016

Aug. 17, 2016

Hi Dillo developers, I stumbled upon a page with a lot of code snippets wrapped in a <pre> block, where Dillo seems to have a rendering problem: Underscores `_' are not drawn. I stripped down this real-world-example to the attached minimal html file which reproduces the problem: The page should render as follows: ============================================ softpoint_with_block() { { echo ""; } | ./softpoint.x leshouches } ============================================ However, in the development version of Dillo it renders as follows: ============================================ softpoint with block() { { echo ""; } | ./softpoint.x leshouches } ============================================ As you can see, the underscores in the function softpoint_with_block() are not drawn in Dillo. However, the underscores are drawn correcty if you * remove the style="..." specification from the <pre> block or * remove the line { echo ""; } | ./softpoint.x leshouches from the <pre> block content. Best regards, Alex

4 14

Underscores not drawn in pre with background color
by michael.baeuerle＠stz-e.de Aug. 15, 2016

Aug. 15, 2016

Nick Warne wrote: > On Sat, 23 Jul 2016 11:25:18 +0100 Nick Warne <nick at linicks.net> wrote: > > On Sat, 23 Jul 2016 11:13:19 +0100 Nick Warne <nick at linicks.net> wrote: > > > On Sat, 23 Jul 2016 10:01:59 +0100 Nick Warne <nick at linicks.net> wrote: > > > > On Fri, 22 Jul 2016 20:12:59 +0300 John Found <johnfound at asm32.info> wrote: > > > > > > > > > > Confirmed. I am using "Liberation Mono", but with "DejaVu Sans > > > > > Mono" have the same problem. It is probably because of the > > > > > characters height - the next row of text overwrites the > > > > > previous. The question is whether this is because of Dillo or > > > > > because of FLTK. > > > > > > > > > > The same font, used in Firefox renders correctly. > > > > > > > > This looks like a bug in the font: > > > > > > > > http://dejavu-fonts.org/wiki/Bugs/Archived > > > > > > > > (you need to scroll down a bit). > > > > > > > > I have version 2.34 installed - will see if I can reproduce it > > > > later. > > > > > > OK, I get the same issue. But if you change the font size, thus: > > > > > > <pre style="background-color: white; > > > font-size:105%;">softpoint_with_block() { > > > > > > the underscores are visible. > > > > Huh! Strangely the underscores become visible with font size set to > > 95% too! Only 100% renders them invisible? > > OK, turning off 'use embedded CSS' makes them visible too. > > CSS parsing error? Please check whether the problem is related to this FLTK STR I created some days ago: <http://www.fltk.org/str.php?L3321>

2 1

Good news in dillo's rendering!
by jcid＠dillo.org Aug. 4, 2016

Aug. 4, 2016

Hi there, Here go some good news. Originally I was to send this internally to the core devs, but as we've benefitted from the feedback of active users in the list, and their experiences with the patches (before/afterwards), on the sites they usually browse, it looks like a good idea to do it again. Since June 6, when this thread [1] was started by Sebastian, I've been investigating/working in problems related to it. This led to some extensive rendering tests that catched a laundry list of problems with our current tip (#4643 today). This is a list with brief explanations, taken from the testing data tables I've gathered so far: Problems: 1: overwrites text with images. 2: crops images (aspect ratio). 3: different layout. 4: overwrites text with text float. 5: overwrites text with text. 6: CPU HOG with: tmp.num.html, tmp.num.small.html 7: Missing page sections (sometimes works for the same page). 8: Small images cut in two sometimes ("ESP", "CRO", ...) 9: Wrong aspect ratio for images (text line height) 10: Page drawn with offset (but browser thinks other section is on screen). There're test cases for each one, and most of them were taken and reduced from real pages. Having reduced test cases is good, reduced and isolated tests is better, but the good news is that I have a couple of patches that solve all of them! I'm not saying dillo will be error-free hereafter, but that the root of a whole family of problems has been found and fixed, and this will make future testing much simpler. GROWS2 is the "Grand Redesign Of Widget Sizes" v2 by Sebastian. This is a very powerful and flexible concept whose design allows floats, layers (and absolutes in the future, and more). It has proven very fast so far, even without optimizations. Well the patches are two simple but deep changes in the way markSizeChange() and queueResize() interact. The patch idea is close to graph coverage recursions (with pruning), applied to the widget tree. I'd like to commit it, upload the test suite I'm using, and show the testing data tables I've gathered so everyone can check it with their use cases and report on it. @Sebastian: May I, or would you prefer to review them before? (the patches are the "middle ground" you mentioned. Solve the dw hog problems at dw level, not in the parser, and reuse code you've already seen. A couple of days should be enough to review) @Sebastian: Problem #10 is not related to GROWS2, but a three year old bug discovered during the tests. So let's get it done first. How to reproduce it: Go to [2], wait a bit for most images to load, then use "find text" to find the "re-re" string, scroll a bit downwards to find the image and center it. Go back then forward; no image! But dillo thinks it *is* there so move the cursor to the center of the page and you'll see the hand cursor, wait for the tooltip and drag it a bit downwards to the right. Dillo will repaint from the image data. Bisect shows the bug was introduced by #2863. Attached is a simple concept patch for it. Please review/fix/commit, as I don't know the updated invariants of resize idle. [1] http://lists.dillo.org/pipermail/dillo-dev/2016-June/010887.html [2] http://tinyurl.com/huvf6pn -- Cheers Jorge.-

2 4

Successful build on OS X
by gears_of_war__＠hotmail.com Aug. 4, 2016

Aug. 4, 2016

Dillo builds an runs on mac os x 10.5.8 (ppc32) with fltk-1.3.3. It runs great!

1 0

ImageMagick for SVG and other image types?
by jgaffney＠lawrenceville.org July 20, 2016

July 20, 2016

At this point Dillo supports the display of GIF, PNG, and JPG, but SVG is used heavily by sites like, for example, Wikipedia. Has the Magick++ library in ImageMagick been considered for supporting these other image formats? The FLTK people seem enthusiastic about the Imago library in spite of its alpha state of development; librsvg, which looks, at least to my untutored eye, like it requires a fair amount of voodoo to use, is apparently no longer actively supported and would at any rate only provide SVG support; but ImageMagick is pretty standard with Linux distributions, and the Magick++ interface makes conversions from any format to PNG for the purposes of display extremely easy. In src/misc.c, at the end of the image part of the else-if ladder in a_Misc_get_content_type_from_data(), one could add another "rung" that uses Data and Size to create a Magick::Blob, and from this a Magick::Image, then use Magick::Image.write() to write this to another Magick::Blob of type PNG, and then replace Data and Size with those of the resulting Magick::Blob. A try-catch block would catch the cases where Data is not an image. Altogether this sort of "cheat" would require very few lines of code to implement. And the Magick++-config utility could supply the needed -D..., -I..., -l... flags to the configure script. I'm not suggesting this is an ideal long-term solution, but in the interim would at least allow the display of other image types. The most recent mention of this on the mailing list seems to be Jorge's indication on 22 April 2016 that No, there's no SVG image support in dillo yet. It should not be hard to implement though, but it needs an effort similar to GIF or PNG or JPEG code. Patch welcomed! ;) But surely someone has thought of ImageMagick before. Are there objections to using it? And if so, maybe a flag could be set by the configure script to conditionally compile this in for those who want it? (If this is pursued, the configure script should probably also check that the version of ImageMagick is recent enough to have been patched against that serious exploit in just this sort of conversion code.) A test program shows that the invocation of ImageMagick and conversions really are as simple as the steps outlined above. But I would be happy to make an attempt at a patch, if you don't mind this being undertaken by an amateur.

1 1