Hello, Sometimes the page text is not entirely wrapped to the browser window, resulting in lines extending off screen, which is a pain. This can be especially visible if remote CSS is disabled, and/or you are using a portrait display. Maybe this can be partially mitigated by having zoom buttons in the toolbar. Beyond that, there are many other reasons why you might want to make the text larger or smaller, depending on the page and display configuration, accessibility needs, etc. It's not always practical to edit dillorc and restart for every page in question. I think one of the Dillo forks did it before. Can we just dynamically adjust the 'font_factor' setting? Any interest in this? Regards, Alex
Sounds like a nice feature. and/or as menu items On Wednesday, 1 May 2024 18:02:39 EDT, a1ex@dismail.de wrote:
Hello,
Sometimes the page text is not entirely wrapped to the browser window, resulting in lines extending off screen, which is a pain. This can be especially visible if remote CSS is disabled, and/or you are using a portrait display. Maybe this can be partially mitigated by having zoom buttons in the toolbar. Beyond that, there are many other reasons why you might want to make the text larger or smaller, depending on the page and display configuration, accessibility needs, etc. It's not always practical to edit dillorc and restart for every page in question.
I think one of the Dillo forks did it before. Can we just dynamically adjust the 'font_factor' setting? Any interest in this?
Regards, Alex
Hi, On Thu, May 02, 2024 at 09:53:39AM -0400, Charles E. Lehner wrote:
Sounds like a nice feature. and/or as menu items
On Wednesday, 1 May 2024 18:02:39 EDT, a1ex@dismail.de wrote:
Hello,
Sometimes the page text is not entirely wrapped to the browser window, resulting in lines extending off screen, which is a pain.
What do you mean by "resulting in lines extending off screen"? If you mean the Dillo viewport, that is probably caused by some missing CSS feature, which we should fix too, but shouldn't happen with CSS disabled.
This can be especially visible if remote CSS is disabled, and/or you are using a portrait display. Maybe this can be partially mitigated by having zoom buttons in the toolbar. Beyond that, there are many other reasons why you might want to make the text larger or smaller, depending on the page and display configuration, accessibility needs, etc. It's not always practical to edit dillorc and restart for every page in question.
I agree.
I think one of the Dillo forks did it before. Can we just dynamically adjust the 'font_factor' setting? Any interest in this?
I think we should implement a zoom control, like on other browsers with Control + / Control -. Here is an issue on this topic: https://github.com/dillo-browser/dillo/issues/21 I have a patch that implements it by adding a zoom factor that changes with Ctrl + and Ctrl -, but it doesn't work well in some cases. Notice that the font_factor is not the same as "zooming" all elements. For example, if you load the old website and try to zoom with Ctrl +, the top image is not scaled accordingly: $ dillo https://dillo-browser.github.io/old/index.html Here is the branch[1] and patch[2]: [1]:https://github.com/dillo-browser/dillo/compare/zoom-control [2]:https://github.com/dillo-browser/dillo/commit/bfa6dfae82887ba51749cf4b713a75... I think it would made more sense to scale the complete page, and not only the font, but that would require a bit more work. We would need this anyway to implement proper DPI scaling. Rodrigo.
Hi Rodrigo,
Sometimes the page text is not entirely wrapped to the browser window, resulting in lines extending off screen, which is a pain.
What do you mean by "resulting in lines extending off screen"? If you mean the Dillo viewport, that is probably caused by some missing CSS feature, which we should fix too, but shouldn't happen with CSS disabled.
Here is an example: https://news.ycombinator.com/item?id=40250573 Viewing the page in Dillo with CSS turned off, some of the text runs off the window and I have to scroll right to see it. With CSS turned on, the text is very small and impossible to read on my monitor (but now the offending lines fit on the window). In Firefox, the text appears correctly and is always wrapped to the window regardless of zoom level.
I think we should implement a zoom control, like on other browsers with Control + / Control -. Here is an issue on this topic:
https://github.com/dillo-browser/dillo/issues/21
I have a patch that implements it by adding a zoom factor that changes with Ctrl + and Ctrl -, but it doesn't work well in some cases. Notice that the font_factor is not the same as "zooming" all elements.
I have tested your patch and it works pretty well, minus the image scaling issue you mentioned. One thing I will note however, on a TKL (ten key less) keyboard, there is no dedicated '+' key, so zooming in doesn't work. On a US layout for example, the key is =/+, but pressing Ctrl-Shift-= doesn't have the expected result. I changed the mapping in keys.cc to Ctrl-= and it works for me, but would vary for other localizations. Regards, Alex
Hi, I'm adding Hacker News in CC. On Sat, May 04, 2024 at 11:20:25AM +0200, a1ex@dismail.de wrote:
Hi Rodrigo,
Sometimes the page text is not entirely wrapped to the browser window, resulting in lines extending off screen, which is a pain.
What do you mean by "resulting in lines extending off screen"? If you mean the Dillo viewport, that is probably caused by some missing CSS feature, which we should fix too, but shouldn't happen with CSS disabled.
Here is an example: https://news.ycombinator.com/item?id=40250573
Viewing the page in Dillo with CSS turned off, some of the text runs off the window and I have to scroll right to see it. With CSS turned on, the text is very small and impossible to read on my monitor (but now the offending lines fit on the window). In Firefox, the text appears correctly and is always wrapped to the window regardless of zoom level.
I see what is going on. By default, Dillo doesn't wrap the content of <pre> elements. But, the following rule in HN CSS should cause it to wrap the text at spaces and newlines:
pre { overflow: auto; padding: 2px; white-space: pre-wrap; overflow-wrap:anywhere; }
But Dillo fails to process the CSS document because it doesn't understand a previous rule:
input[type=\"submit\"] { font-family:Verdana, Geneva, sans-serif; }
The 'input[type=\"submit\"]' selector is causing the CSS parser to ignore the rest of the CSS style sheet. I believe this is a bug in HN CSS, as it should be:
input[type="submit"] { font-family:Verdana, Geneva, sans-serif; }
Which works properly, I attached a reproducer. I have to check what is going on in the parser, by I suspect the first \" causes the parser to enter "string mode", and then the second \" is parsed as a quote inside the string because it is escaped, not as the closing quote. So everything else in the CSS file is treated as the content of the string. This should be fixed on HN side. We should make the CSS parser more robust to these problems. In the meanwhile, you can add this workaround in ~/.dillo/style.css to make <pre> wrapped by default in all pages:
pre { white-space: pre-wrap; }
Best, Rodrigo
We should make the CSS parser more robust to these problems.
In the meanwhile, you can add this workaround in ~/.dillo/style.css to make <pre> wrapped by default in all pages:
pre { white-space: pre-wrap; }
That does the trick, thanks very much! This has been a frustration for quite a while, and I'm pretty sure I have run into other sites in the past with similar issues. Hopefully never again :) Thanks again, Alex
Hi, I reply to this in another thread to keep the topic about the zoom feature. On Sat, May 04, 2024 at 11:20:25AM +0200, a1ex@dismail.de wrote:
I have tested your patch and it works pretty well, minus the image scaling issue you mentioned.
Thanks for testing!
One thing I will note however, on a TKL (ten key less) keyboard, there is no dedicated '+' key, so zooming in doesn't work. On a US layout for example, the key is =/+, but pressing Ctrl-Shift-= doesn't have the expected result. I changed the mapping in keys.cc to Ctrl-= and it works for me, but would vary for other localizations.
I choose the Ctrl + / Ctrl - as it is the default in other browsers, but I mostly use Ctrl and the mouse wheel. I haven't been able to figure it out how to make it work yet on Dillo, but maybe that would help you too. In any case, you can adjust the ~/.dillo/keysrc file to you needs[1], no need to change the source code. [1]: https://dillo-browser.github.io/user_help.html#keysrc Best, Rodrigo.
Hi, On Sat, May 04, 2024 at 01:44:11PM +0200, Rodrigo Arias wrote:
One thing I will note however, on a TKL (ten key less) keyboard, there is no dedicated '+' key, so zooming in doesn't work. On a US layout for example, the key is =/+, but pressing Ctrl-Shift-= doesn't have the expected result. I changed the mapping in keys.cc to Ctrl-= and it works for me, but would vary for other localizations.
I choose the Ctrl + / Ctrl - as it is the default in other browsers, but I mostly use Ctrl and the mouse wheel. I haven't been able to figure it out how to make it work yet on Dillo, but maybe that would help you too.
I just merged support for zoom control: https://github.com/dillo-browser/dillo/pull/156 You can use both Ctrl-+ (non-US) or Ctrl-= (US) by default to zoom in. Best, Rodrigo.
Hi Rodrigo, On Tue, 25 Jun 2024 21:33:54 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
I just merged support for zoom control:
Thanks very much for making this feature happen! One thing which I would suggest is also having optional toolbar buttons to control this. I would like to think that the Dillo project strives for maximum accessibility whenever possible, since pretty much all of the other features are available with mouse controls. There are a variety of scenerios where this can be desirable. Maybe I could attempt to kludge together a patch at some point, if there are no other more qualified takers, of course. Regards, Alex
Hi, On Wed, Jun 26, 2024 at 03:26:59PM +0200, a1ex@dismail.de wrote:
Hi Rodrigo,
On Tue, 25 Jun 2024 21:33:54 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
I just merged support for zoom control:
Thanks very much for making this feature happen!
One thing which I would suggest is also having optional toolbar buttons to control this.
Yeah, I thought about adding three new menu items in the main menu or under a sub-menu, but I like the idea of Firefox and Chromium where they placed both the [-] [+] buttons inside a main menu item. Not sure how hard it would be to do with FLTK.
I would like to think that the Dillo project strives for maximum accessibility whenever possible, since pretty much all of the other features are available with mouse controls. There are a variety of scenerios where this can be desirable.
I would like to make Dillo more accessible, but we would need more developers to help. I checked a bit how to integrate it with orca or other text readers but I don't have much experience on that area.
Maybe I could attempt to kludge together a patch at some point, if there are no other more qualified takers, of course.
Thanks, that would be nice. Best, Rodrigo.
On Wed, 26 Jun 2024 21:16:47 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
One thing which I would suggest is also having optional toolbar buttons to control this.
Yeah, I thought about adding three new menu items in the main menu or under a sub-menu, but I like the idea of Firefox and Chromium where they placed both the [-] [+] buttons inside a main menu item.
Not sure how hard it would be to do with FLTK.
I briefly looked at adding this to the Page menu, it certainly looks possible, but it's a little beyond me at the moment. Same with toolbar buttons. So, right now I just tried to find the least complicated way to zoom with the mouse. Here is a patch which allows zooming in and out using the Refresh button. Right clicking on it zooms the page in. Middle clicking zooms out. It's not especially intuitive, but it's simple and it works. $ diff -u ui.cc.orig ui.cc.mod --- ui.cc.orig Fri Jul 5 15:04:00 2024 +++ ui.cc.mod Fri Jul 5 16:07:48 2024 @@ -333,6 +333,10 @@ case UI_RELOAD: if (b == FL_LEFT_MOUSE) { a_UIcmd_reload(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_RIGHT_MOUSE) { + a_UIcmd_zoom_in(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_MIDDLE_MOUSE) { + a_UIcmd_zoom_out(a_UIcmd_get_bw_by_widget(wid)); } break; case UI_SAVE: Regards, Alex
Hi Alex,
Here is a patch which allows zooming in and out using the Refresh button. Right clicking on it zooms the page in. Middle clicking zooms out. It's not especially intuitive, but it's simple and it works.
I agree is not very intuitive, maybe using the scroll wheel may be more clear. But still, tying it to the refresh button is weird to me. On the other hand, I like that you can see the whole page while changing the zoom level using the mouse (which doesn't happen in other browsers). I'm thinking if it could make sense to add another "appearance" bar (usually hidden) like the "find text" where we can put some knobs to change the page appearance, like the zoom buttons or sliders but also maybe some of the CSS options too. I think this would also make more sense if we can select multiple "user" styles to implement some king of reader mode, as you will want to see the effect without covering the canvas. Rodrigo.
On Sat, 6 Jul 2024 14:30:01 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
Hi Alex,
Here is a patch which allows zooming in and out using the Refresh button. Right clicking on it zooms the page in. Middle clicking zooms out. It's not especially intuitive, but it's simple and it works.
I agree is not very intuitive, maybe using the scroll wheel may be more clear. But still, tying it to the refresh button is weird to me.
On the other hand, I like that you can see the whole page while changing the zoom level using the mouse (which doesn't happen in other browsers). I'm thinking if it could make sense to add another "appearance" bar (usually hidden) like the "find text" where we can put some knobs to change the page appearance, like the zoom buttons or sliders but also maybe some of the CSS options too.
I think this would also make more sense if we can select multiple "user" styles to implement some king of reader mode, as you will want to see the effect without covering the canvas.
Your idea of an "appearance" bar sounds interesting. I was originally thinking it would be neat to have the zoom buttons on the bottom next to the bugmeter, similar to what you are suggesting. Since that sounds more like a long-term goal, I have come up with a patch to create a dedicated zoom button on the toolbar. Left-click zooms in, right-click zooms out. Its just a proof of concept, but if you like the idea, maybe I could polish it up and make an optional setting for it, etc. Here you go: diff -u ./pixmaps.h mod/pixmaps.h --- ./pixmaps.h Sat Jul 6 18:03:43 2024 +++ mod/pixmaps.h Sat Jul 6 18:23:27 2024 @@ -1410,6 +1410,28 @@ }; /* XPM */ +static const char *const zoom_xpm[] = { +"16 16 2 1", +" c None", +"@ c gray70", +" ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" @@@@@@@@@@@@@ ", +" @@@@@@@@@@@@@ ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" "}; + +/* XPM */ static const char *const new_s_xpm[] = { "11 11 35 1", " c None", diff -u ./ui.cc mod/ui.cc --- ./ui.cc Sat Jul 6 18:26:52 2024 +++ mod/ui.cc Sat Jul 6 18:03:57 2024 @@ -38,7 +38,7 @@ struct iconset { Fl_Image *ImgMeterOK, *ImgMeterBug, - *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, + *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, *ImgZoom, *ImgClear,*ImgSearch, *ImgHelp, *ImgLeft, *ImgLeftIn, *ImgRight, *ImgRightIn, *ImgStop, *ImgStopIn; }; @@ -51,6 +51,7 @@ new Fl_Pixmap(save_xpm), new Fl_Pixmap(bm_xpm), new Fl_Pixmap(tools_xpm), + new Fl_Pixmap(zoom_xpm), new Fl_Pixmap(new_s_xpm), new Fl_Pixmap(search_xpm), new Fl_Pixmap(help_xpm), @@ -70,6 +71,7 @@ new Fl_Pixmap(save_s_xpm), new Fl_Pixmap(bm_s_xpm), new Fl_Pixmap(tools_s_xpm), + new Fl_Pixmap(zoom_xpm), new Fl_Pixmap(new_s_xpm), standard_icons.ImgSearch, standard_icons.ImgHelp, @@ -356,6 +358,13 @@ wid->y() + wid->h()); } break; + case UI_ZOOM: + if (b == FL_LEFT_MOUSE) { + a_UIcmd_zoom_in(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_RIGHT_MOUSE) { + a_UIcmd_zoom_out(a_UIcmd_get_bw_by_widget(wid)); + } + break; default: break; } @@ -433,6 +442,7 @@ Stop = make_button("Stop", icons->ImgStop, icons->ImgStopIn, UI_STOP); Bookmarks = make_button("Book", icons->ImgBook, NULL, UI_BOOK); Tools = make_button("Tools", icons->ImgTools, NULL, UI_TOOLS); + Zoom = make_button("Zoom", icons->ImgZoom, NULL, UI_ZOOM); Back->set_tooltip("Previous page"); Forw->set_tooltip("Next page"); @@ -442,6 +452,7 @@ Stop->set_tooltip("Stop loading"); Bookmarks->set_tooltip("View bookmarks"); Tools->set_tooltip("Settings"); + Tools->set_tooltip("Zoom"); } /** diff -u ./ui.hh mod/ui.hh --- ./ui.hh Sat Jul 6 18:03:43 2024 +++ mod/ui.hh Sat Jul 6 18:03:57 2024 @@ -23,6 +23,7 @@ UI_STOP, UI_BOOK, UI_TOOLS, + UI_ZOOM, UI_CLEAR, UI_SEARCH } UIButton; @@ -125,7 +126,7 @@ CustGroupVertical *TopGroup; CustButton *Back, *Forw, *Home, *Reload, *Save, *Stop, *Bookmarks, - *Tools, *Clear, *Search, *Help, *BugMeter, *FileButton; + *Tools, *Zoom, *Clear, *Search, *Help, *BugMeter, *FileButton; CustGroupHorizontal *LocBar, *NavBar, *StatusBar; Fl_Input *Location; CustProgressBox *PProg, *IProg; Regards, Alex
participants (3)
-
a1ex＠dismail.de -
Charles E. Lehner -
Rodrigo Arias