- Dillo-dev - lists.mailman3.com

Underscores not drawn in pre with background color

by Hole.destructor＠gmx.de

Hi Jorge, then maybe it is an FLTK issue? I'm using Debian Jessie GNU/Linux 4.6.0-0.bpo.1-amd64 FLTK 1.3.1 Best regards, Alex On Thu, Jul 21, 2016 at 08:14:20PM -0400, Jorge Arellano Cid wrote: > Hi Alexander, > > On Thu, Jul 21, 2016 at 09:50:22PM +0200, Alexander Voigt wrote: > > 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. > > The attached example renders OK here. > Maybe someone else can reproduce it. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

July 22, 2016

Underscores not drawn in pre with background color

by jcid＠dillo.org

Hi Alexander, On Thu, Jul 21, 2016 at 09:50:22PM +0200, Alexander Voigt wrote: > 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. The attached example renders OK here. Maybe someone else can reproduce it. -- Cheers Jorge.-

July 22, 2016

Underscores not drawn in pre with background color

by Hole.destructor＠gmx.de

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

July 21, 2016

ImageMagick for SVG and other image types?: Pseudo Code

by jgaffney＠lawrenceville.org

I was going to attempt a sort of proof-of-concept patch, and still include a mix of code and pseudo-code below, but see that a change would be required in the way a_Misc_get_content_type_from_data() (in src/misc.[hc]) is called from elsewhere in Dillo -- but this would not require much change, since, as far as I can see, a_Misc_get_content_type_from_data() is called from only two places in the rest of the source code. The problem is that the data being parsed is from a Dstr, but only the str and the value of the len members of this Dstr are passed to a_Misc_get_content_type_from_data(), so that the Dstr is not modifiable. If a pointer to the Dstr were passed instead, it would be modifiable, which would then allow for conversion of image types other than GIF, PNG, and JPG to be converted to PNG for the purposes of display by replacing the original Dstr data with the data for the converted image. (This would mean that Dillo would be using and caching the PNG into which the original image was converted, rather than the original, but this is only proposed as an interim means of at least displaying other, currently unsupported, image types.) In a mix of code and pseudo-code: Along with the configure.ac block to use the Magick++-config utility to test for the Magick++ library and its version and to set the corresponding compiler and linker flags, and a call in main() to Magick::InitializeMagick(NULL), replace the current src/misc.c block starting at line 161 } else if (Size >= 2 && !strncmp(p, "\xff\xd8", 2)) { /* JPEG has the first 2 bytes set to 0xffd8 in BigEndian - looking * at the character representation should be machine independent. */ Type = DT_IMAGE_JPG; st = 0; /* Text */ } else { /* Heuristic for "text/plain" ... */ with something like } else if (Size >= 2 && !strncmp(p, "\xff\xd8", 2)) { /* JPEG has the first 2 bytes set to 0xffd8 in BigEndian - looking * at the character representation should be machine independent. */ Type = DT_IMAGE_JPG; st = 0; } else if (ConvertImage(ModifiablePtrToData, & DataLen)) { Type = DT_IMAGE_PNG; st = 0; /* Text */ } else { /* Heuristic for "text/plain" ... */ and adding to src/misc.h #include "miscconv.hh" with two new files: a header miscconv.hh with #ifndef __MISCCONV_HH__ #define __MISCCONV_HH__ #ifdef __cplusplus extern "C" { #endif #include <stdlib.h> int ConvertImage (void *, size_t *); #ifdef __cplusplus } #endif #endif and, for the source file miscconv.cc, something like #include "miscconv.hh" #include <Magick++.h> extern "C" int ConvertImage ( char * Data, size_t * Size ) { try { Magick :: Blob blob ( Data, Size ), PngBlob; // This ctor will throw an exception if Data is not image data: Magick :: Image image ( blob ); // From the magic used by the `file' command, it seems that identifying SVG // data by its magic would be pretty involved, and as far as I can tell // there is no way in Magick++ to check the type of the image data // (including whether it is image data to begin with) without constructing // an Image -- which, if the data is any kind of image recognized by // ImageMagick, seems automatically to convert the image to some internal // format. And in consequence it seems that any security policies, such as // limits on image sizes or types, would have to be set via the local // ImageMagick policy (in the ImageMagick policy.xml in /etc or the like). // Now that the Image has been constructed, if desired its native type can be // determined by, e.g., Image::format(). Otherwise, one can // just proceed with the conversion of images of any format. // The following call could also throw an exception: image . write ( & PngBlob, "PNG"); // And now we just need to rewire things for the converted image: Code here to deallocate Data, allocate a new pointer according to PngBlob.length(), replace Data with the new pointer, and copy PngBlob.data() to it. } catch ( Magick :: Exception & e ) { // The ImageMagick docs cover the rather wide array of possible warnings and // errors, and a MSG could be crafted from these, but for the present purposes // any exception means the failure to return a displayable PNG. Code to do whatever with e.what() ... return 0; } return 1; } John Gaffney <jgaffney at lawrenceville.org> writes: > 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. > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

July 20, 2016

ImageMagick for SVG and other image types?

by jgaffney＠lawrenceville.org

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.

July 18, 2016

Good news in dillo's rendering!

by sgeerken＠dillo.org

On Mi, Jul 13, 2016, Jorge Arellano Cid wrote: > 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. It's actually called "SRDOP" ("Size Requisitions Depending On Positions). See - http://www.dillo.org/dw/html/dw-grows.html - http://www.dillo.org/dw/html/dw-size-request-pos.html As to current bugs, most of them fall into either one category: 1. missing rendering updates: this results in rendering errors (wrong positions etc.); 2. inefficient (too many) updates: this results in CPU hogging. You see that these are complementary. :-) The focus should now be on the first category, and I've still at least one open issue here, which is neither addressed by Jorge's patches. Problems from the second category are best fixed after this. Sebastian

July 17, 2016

cppcheck on Dillo source

by sgeerken＠dillo.org

On Di, Jul 12, 2016, Jorge Arellano Cid wrote: > > Checking ../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc:654]: (error) Possible null pointer dereference: vloat > > Well, the code should never reach there. > Not changed. > > @Sebastian, BTW, coincidentally I'm using something like: > > SortedFloatsVector *list; > list = isSubRefLeftFloat(ref) ? leftFloats : rightFloats; > Float *vloat = list->get (getFloatIndexFromSubRef (ref)); > > in some patches I have, which also silence cppcheck. But maybe the > original construct was meant for adding more options (like absolute > positioned floats), but those may end in a third floats array, so I'm > not sure. Is it safe to use the above construct, or should I leave it > as is? OOFFloatsMgr only deals with floats, so it should be safe. However, I'd like to keep assertNotReached() there, to make debugging easier. Sebastian

July 17, 2016

Good news in dillo's rendering!

by jcid＠dillo.org

Hi there, OK, the patches were just committed, there're four instead of two and the last one has the full test suite results inside the comments in Hg. These patches work very well so far. The idea is to get your testing and feedback. I still have some ideas and cleanups for them, but that will take more time, and this set is already working and very fast. Enjoy! PD: a bit overworked Jorge. :-P -- Cheers Jorge.-

July 17, 2016

Good news in dillo's rendering!

by jcid＠dillo.org

On Wed, Jul 13, 2016 at 01:37:12PM -0400, Jorge Arellano Cid wrote: > [...] > @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 As usual, the attachment arrives later... ;) -- Cheers Jorge.-

July 13, 2016

Good news in dillo's rendering!

by jcid＠dillo.org

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.-

July 13, 2016