- Dillo-dev - lists.mailman3.com

Weirdly scaled images (again)

by fusionfile＠gmail.com

On 2015-08-19 17:32, Johannes Hofmann wrote: > as it was mentioned in this thread already the image scaling issue > is fixed for quite some time in the main line of the dillo repo. I have downloaded and installed the latest Dillo version 3.1-dev. With the test file below the two images have the same size despite setting width to 25 percent on the second image. Do you get the same result? -- August <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Dillo Test</title> </head> <body> <div><img alt="Dillo logo" src="http://www.dillo.org/db1.png" /></div> <div><img alt="Dillo logo" src="http://www.dillo.org/db1.png" width="25%" /></div> </body> </html>

Aug. 19, 2015

Weirdly scaled images (again)

by johannes.hofmann＠gmx.de

Hi Jorge, On Tue, Aug 18, 2015 at 07:45:09PM -0300, Jorge Arellano Cid wrote: > On Mon, Aug 17, 2015 at 09:35:09PM +0200, August Karlstrom wrote: > > On 2015-08-02 16:52, August Karlstrom wrote: > > >Apparently some (or most?) browsers, Firefox for instance, do uniform > > >scaling when only one of the width or height attribute is set on an img > > >element. Dillo does non-uniform scaling and changes only the specified > > >dimension. Here is what the reference has to say about it: > > > > > >"When the object is an image, it is scaled. User agents should do their > > >best to scale an object or image to match the width and height specified > > >by the author." > > > > > >http://www.w3.org/TR/html401/struct/objects.html#edef-IMG > > > > > >It seems to be a question of interpretation. > > > > I have posted the question on Stack Overflow: > > > > http://stackoverflow.com/questions/31773161/specifying-only-width-or-height… > > FWIW, IMHO, it should scale respecting the original image ratio > (just pragmatics). > > AFAIR, it was/could-be done this way by dillo (using CSS hints) but > somewhere in the redesign (GROWS) these image-size hints were lost. > @Sebastian, @Johannes, please correct me if I'm wrong here. as it was mentioned in this thread already the image scaling issue is fixed for quite some time in the main line of the dillo repo. Cheers, Johannes

Aug. 19, 2015

Weirdly scaled images (again)

by fusionfile＠gmail.com

On 2015-08-19 00:45, Jorge Arellano Cid wrote: > On Mon, Aug 17, 2015 at 09:35:09PM +0200, August Karlstrom wrote: >> I have posted the question on Stack Overflow: >> >> http://stackoverflow.com/questions/31773161/specifying-only-width-or-height… > > FWIW, IMHO, it should scale respecting the original image ratio > (just pragmatics). > > AFAIR, it was/could-be done this way by dillo (using CSS hints) but > somewhere in the redesign (GROWS) these image-size hints were lost. > @Sebastian, @Johannes, please correct me if I'm wrong here. After a little experimentation it seems like the image ratio is respected when width or height is set in pixels but not when a percentage is used, for instance <img alt="Some image" src="some-image.jpg" width="25%" /> I use Dillo version 3.0.4 in Debian Jessie (stable). -- August

Aug. 19, 2015

Weirdly scaled images (again)

by jcid＠dillo.org

On Mon, Aug 17, 2015 at 09:35:09PM +0200, August Karlstrom wrote: > On 2015-08-02 16:52, August Karlstrom wrote: > >Apparently some (or most?) browsers, Firefox for instance, do uniform > >scaling when only one of the width or height attribute is set on an img > >element. Dillo does non-uniform scaling and changes only the specified > >dimension. Here is what the reference has to say about it: > > > >"When the object is an image, it is scaled. User agents should do their > >best to scale an object or image to match the width and height specified > >by the author." > > > >http://www.w3.org/TR/html401/struct/objects.html#edef-IMG > > > >It seems to be a question of interpretation. > > I have posted the question on Stack Overflow: > > http://stackoverflow.com/questions/31773161/specifying-only-width-or-height… FWIW, IMHO, it should scale respecting the original image ratio (just pragmatics). AFAIR, it was/could-be done this way by dillo (using CSS hints) but somewhere in the redesign (GROWS) these image-size hints were lost. @Sebastian, @Johannes, please correct me if I'm wrong here. -- Cheers Jorge.-

Aug. 18, 2015

Weirdly scaled images (again)

by singpolyma＠singpolyma.net

>Apparently some (or most?) browsers, Firefox for instance, do uniform >scaling when only one of the width or height attribute is set on an img >element. Yes, this is the right thing to do and is the only way images should generally be used on the web (since you always want uniform scaling and don't get it when setting both width and height, so only one of width or height should ever be set).

Aug. 17, 2015

Weirdly scaled images (again)

by fusionfile＠gmail.com

On 2015-08-02 16:52, August Karlstrom wrote: > Apparently some (or most?) browsers, Firefox for instance, do uniform > scaling when only one of the width or height attribute is set on an img > element. Dillo does non-uniform scaling and changes only the specified > dimension. Here is what the reference has to say about it: > > "When the object is an image, it is scaled. User agents should do their > best to scale an object or image to match the width and height specified > by the author." > > http://www.w3.org/TR/html401/struct/objects.html#edef-IMG > > It seems to be a question of interpretation. I have posted the question on Stack Overflow: http://stackoverflow.com/questions/31773161/specifying-only-width-or-height… -- August

Aug. 17, 2015

weirdly scaled images

by sgeerken＠dillo.org

On Sun, Aug 16, 2015, v4hn wrote: > On Sun, Aug 16, 2015 at 01:09:24AM +0200, v4hn wrote: > > It seems there are at least two people (August and I) who await an 3.1 release. :-) > > Seems I've been too rash. One of the pages August mentioned (http://www.dn.se) > produces a CPU lock 5 out of 10 times over here that is unrelated to the aspect ratio bug though. > In case anyone is interested, please find the backtrace below. This is why it did not go into the release. I'm currently working on another approach to reduce these CPU hogging problems, which still orrur, see [1]; although there has not been much work recently. (And the "dillo_grows" version will not work at all.) The problems are caused by floats; so disabling them by adding * { float: none !important } into ~/.dillo/style.css should help. Sebastian [1] http://flpsed.org/hgweb/dillo_grows/file/tip/devdoc/dw-size-request-pos.doc

Aug. 16, 2015

Weirdly scaled images (again)

by fusionfile＠gmail.com

On 2015-07-28 17:34, August Karlstrom wrote: > Changing the aspect ratio of an image is something you almost never > want do do, and changing the aspect ratio of a photo is a big no-no. > What's your view on this? Do you use Dillo with CSS disabled? > Actually, I think it would be better if image scaling was not > implemented at all, rather than broken like this. Apparently some (or most?) browsers, Firefox for instance, do uniform scaling when only one of the width or height attribute is set on an img element. Dillo does non-uniform scaling and changes only the specified dimension. Here is what the reference has to say about it: "When the object is an image, it is scaled. User agents should do their best to scale an object or image to match the width and height specified by the author." http://www.w3.org/TR/html401/struct/objects.html#edef-IMG It seems to be a question of interpretation. -- August

Aug. 16, 2015

weirdly scaled images

by me＠v4hn.de

On Sun, Aug 16, 2015 at 01:09:24AM +0200, v4hn wrote: > It seems there are at least two people (August and I) who await an 3.1 release. :-) Seems I've been too rash. One of the pages August mentioned (http://www.dn.se) produces a CPU lock 5 out of 10 times over here that is unrelated to the aspect ratio bug though. In case anyone is interested, please find the backtrace below. Thanks, v4hn === #0 lout::container::untyped::HashSet::findNode (this=0x8e6540, object=0x7fffffffd340) at container.cc:498 #1 0x00000000004a06f9 in lout::container::untyped::HashTable::get (this=<optimized out>, key=<optimized out>) at container.cc:704 #2 0x0000000000478a4f in lout::container::typed::HashTable<lout::object::TypedPointer<dw::Textblock>, dw::OutOfFlowMgr::TBInfo>::get (this=0x858c60, key=0x7fffffffd340) at ../lout/container.hh:524 #3 0x00000000004773ad in dw::OutOfFlowMgr::getTextblock (this=0xaffce0, textblock=0x1150db0) at outofflowmgr.cc:1954 #4 0x0000000000473f8e in dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare (this=0x7fffffffd480, o1=0x11243a0, o2=0x7fffffffd410) at outofflowmgr.cc:292 #5 0x000000000047415f in dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex (this=0xaffcb0, lastGB=0x1150db0, lastExtIndex=-1) at outofflowmgr.cc:350 #6 0x00000000004742e8 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0xaffcb0, textblock=0x1150db0, y=393160, h=1, lastGB=0x1150db0, lastExtIndex=-1, lastReturn=0x7fffffffd56c) at outofflowmgr.cc:424 #7 0x0000000000477509 in dw::OutOfFlowMgr::getBorder (this=0xaffce0, textblock=0x1150db0, side=dw::OutOfFlowMgr::LEFT, y=393160, h=1, lastGB=0x1150db0, lastExtIndex=-1) at outofflowmgr.cc:2001 #8 0x0000000000477439 in dw::OutOfFlowMgr::getLeftBorder (this=0xaffce0, textblock=0x1150db0, y=393160, h=1, lastGB=0x1150db0, lastExtIndex=-1) at outofflowmgr.cc:1971 #9 0x000000000046f48d in dw::Textblock::calcBorders (this=0x1150db0, lastOofRef=-1, height=1) at textblock_linebreaking.cc:2051 #10 0x000000000046cbef in dw::Textblock::balanceBreakPosAndHeight (this=0x1150db0, wordIndex=0, firstIndex=0, searchUntil=0x7fffffffd72c, tempNewLine=false, penaltyIndex=0, borderIsCalculated=true, thereWillBeMoreSpace=0x7fffffffd733, wrapAll=false, diffWords=0x7fffffffd734, wordIndexEnd=0x7fffffffd728, lastFloatPos=0x7fffffffd71c, regardBorder=true, height=0x7fffffffd724, breakPos=0x7fffffffd720) at textblock_linebreaking.cc:910 #11 0x000000000046c7ac in dw::Textblock::wrapWordInFlow (this=0x1150db0, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:746 #12 0x000000000046c3c5 in dw::Textblock::wordWrap (this=0x1150db0, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:606 #13 0x000000000046f045 in dw::Textblock::rewrap (this=0x1150db0) at textblock_linebreaking.cc:1891 #14 0x0000000000460da7 in dw::Textblock::sizeRequestImpl (this=0x1150db0, requisition=0x1151640) at textblock.cc:341 #15 0x000000000049c677 in dw::core::Widget::sizeRequest (this=0x1150db0, requisition=0x1151640) at widget.cc:494 #16 0x000000000046f024 in dw::Textblock::rewrap (this=0x1150010) at textblock_linebreaking.cc:1889 #17 0x0000000000460da7 in dw::Textblock::sizeRequestImpl (this=0x1150010, requisition=0x11b6530) at textblock.cc:341 #18 0x000000000049c677 in dw::core::Widget::sizeRequest (this=0x1150010, requisition=0x11b6530) at widget.cc:494 #19 0x000000000046f024 in dw::Textblock::rewrap (this=0x9aeaf0) at textblock_linebreaking.cc:1889 #20 0x0000000000460da7 in dw::Textblock::sizeRequestImpl (this=0x9aeaf0, requisition=0x11220c0) at textblock.cc:341 #21 0x000000000049c677 in dw::core::Widget::sizeRequest (this=0x9aeaf0, requisition=0x11220c0) at widget.cc:494 #22 0x000000000046f024 in dw::Textblock::rewrap (this=0x1121460) at textblock_linebreaking.cc:1889 #23 0x0000000000460da7 in dw::Textblock::sizeRequestImpl (this=0x1121460, requisition=0xaff2b0) at textblock.cc:341 #24 0x000000000049c677 in dw::core::Widget::sizeRequest (this=0x1121460, requisition=0xaff2b0) at widget.cc:494 #25 0x000000000046f024 in dw::Textblock::rewrap (this=0xd99ad0) at textblock_linebreaking.cc:1889 #26 0x0000000000460da7 in dw::Textblock::sizeRequestImpl (this=0xd99ad0, requisition=0xad03f0) at textblock.cc:341 #27 0x000000000049c677 in dw::core::Widget::sizeRequest (this=0xd99ad0, requisition=0xad03f0) at widget.cc:494 #28 0x000000000046f024 in dw::Textblock::rewrap (this=0xd9f950) at textblock_linebreaking.cc:1889 #29 0x0000000000460da7 in dw::Textblock::sizeRequestImpl (this=0xd9f950, requisition=0x7fffffffdcc0) at textblock.cc:341 #30 0x000000000049c677 in dw::core::Widget::sizeRequest (this=0xd9f950, requisition=0x7fffffffdcc0) at widget.cc:494 #31 0x000000000047587e in dw::OutOfFlowMgr::doFloatsExceedCB (this=0xaffce0, side=dw::OutOfFlowMgr::LEFT) at outofflowmgr.cc:1045 #32 0x0000000000474dee in dw::OutOfFlowMgr::sizeAllocateEnd (this=0xaffce0, caller=0xd9f950) at outofflowmgr.cc:651 #33 0x0000000000461a93 in dw::Textblock::sizeAllocateImpl (this=0xd9f950, allocation=0x7fffffffde70) at textblock.cc:759 #34 0x000000000049d565 in dw::core::Widget::sizeAllocate (this=0xd9f950, allocation=0x7fffffffde70) at widget.cc:993 #35 0x0000000000490c3a in dw::core::Layout::resizeIdle (this=0x76b320) at layout.cc:912 #36 0x000000000047cf6d in dw::fltk::FltkPlatform::generalIdle (this=0x76b2b0) at fltkplatform.cc:630 #37 0x000000000047ced6 in dw::fltk::FltkPlatform::generalStaticIdle (data=0x76b2b0) at fltkplatform.cc:620 #38 0x00007ffff76ed060 in Fl::wait(double) () from /usr/lib/libfltk.so.1.3 #39 0x00007ffff76ed0fd in Fl::run() () from /usr/lib/libfltk.so.1.3 #40 0x000000000040b92e in main (argc=1, argv=0x7fffffffe0c8) at dillo.cc:592

Aug. 15, 2015

weirdly scaled images

by me＠v4hn.de

On Sat, Aug 15, 2015 at 06:44:49PM +0200, Johannes Hofmann wrote: > On Fri, Jul 10, 2015 at 12:55:33AM +0200, v4hn wrote: > > Now, for quite some time I've been using dillo to read news > > on http://www.heise.de and it has always annoyed me > > that some of the images on the main page are weirdly scaled. > > Because these images are of size 160x90 but are scaled to > > what feels like 98% of the window's width, they are barely recognizable > > and distracting. > > I think this is fixed in main line for quite some while. Can you > please try to build from the repo (http://www.dillo.org/source.html) > and try again? Thanks for investigating. You're right. The current code in the repository renders the images correctly. So, I suppose I'll use a repository build of dillo for the time being. Looks like thanks goes to Sebastian Geerken who fixed this issue a year ago. Too bad the fix didn't make it into 3.0.4.1 or 3.0.5 yet. It seems there are at least two people (August and I) who await an 3.1 release. :-) v4hn

Aug. 15, 2015