- Dillo-dev - lists.mailman3.com

Documentation fixes: autolinking

by onepoint＠starurchin.org

Sebastian Geerken wrote: > Sorry for the late response. > > On Sa, Apr 04, 2015, Jeremy Henty wrote: > > > > I wrote: > > > > > Jorge Arellano Cid wrote: > > > > > > > On Mon, Mar 16, 2015 at 03:28:43PM +0000, Jeremy Henty wrote: > > > > > > > > > > Three small patches that fix autolinking errors in the documentation. > > > > > The first two escape the autolinking syntax in a few places where it > > > > > was not intended to be a link. The third fixes a few places where a > > > > > link was intended but the autolink syntax was not quite right. > > > > > > > > > > http://starurchin.org/dillo/patch/doxygen-escape-hash-characters.html > > > > > http://starurchin.org/dillo/patch/doxygen-escape-double-colons.html > > > > > http://starurchin.org/dillo/patch/doxygen-fix-simple-name-refs.html > > > > > > > > > > Comments are welcome. > > > > > > > > > > If these are OK I can push them myself as I have write permission. > > > > > (It's actually easier for me to do it myself because Mercurial Queues > > > > > does not notice when the remote repository has a patch that is > > > > > identical to a patch in its queue and generates spurious errors.) > > > > > > > > +1. > > > > > > > > Just not sure about the last one. I don't know whether it > > > > changes the intended semantic for human readers. > > > > > > I think it actually corrects the semantics. An initial '::' means > > > resolve the name in the top namespace, not the current one, but the > > > class names used in the docs are relative to dw/lout. So I think the > > > patch does the right thing. > > > > Bump! Is it OK for me to push these or is more discussion needed? > > Haven't yet tested them, but they look OK; so push them if they don't > break anything. OK, it is done. > As for "::" vs. "\ref": I added "::" to have a reference at all. I'm > not sure about the exact rules, but Doxygen seems to regard anything > containing "::" as reference. > > If "\ref" works, it looks cleaner IMO. I agree. Regards, Jeremy Henty

April 4, 2015

Documentation fixes: autolinking

by sgeerken＠dillo.org

Sorry for the late response. On Sa, Apr 04, 2015, Jeremy Henty wrote: > > I wrote: > > > Jorge Arellano Cid wrote: > > > > > On Mon, Mar 16, 2015 at 03:28:43PM +0000, Jeremy Henty wrote: > > > > > > > > Three small patches that fix autolinking errors in the documentation. > > > > The first two escape the autolinking syntax in a few places where it > > > > was not intended to be a link. The third fixes a few places where a > > > > link was intended but the autolink syntax was not quite right. > > > > > > > > http://starurchin.org/dillo/patch/doxygen-escape-hash-characters.html > > > > http://starurchin.org/dillo/patch/doxygen-escape-double-colons.html > > > > http://starurchin.org/dillo/patch/doxygen-fix-simple-name-refs.html > > > > > > > > Comments are welcome. > > > > > > > > If these are OK I can push them myself as I have write permission. > > > > (It's actually easier for me to do it myself because Mercurial Queues > > > > does not notice when the remote repository has a patch that is > > > > identical to a patch in its queue and generates spurious errors.) > > > > > > +1. > > > > > > Just not sure about the last one. I don't know whether it > > > changes the intended semantic for human readers. > > > > I think it actually corrects the semantics. An initial '::' means > > resolve the name in the top namespace, not the current one, but the > > class names used in the docs are relative to dw/lout. So I think the > > patch does the right thing. > > Bump! Is it OK for me to push these or is more discussion needed? Haven't yet tested them, but they look OK; so push them if they don't break anything. As for "::" vs. "\ref": I added "::" to have a reference at all. I'm not sure about the exact rules, but Doxygen seems to regard anything containing "::" as reference. If "\ref" works, it looks cleaner IMO. Sebastian

April 4, 2015

Secure: yes, Though Features Missing; and Bugs

by miroslav.rovis1＠zg.ht.hr

On Sat, Apr 04, 2015 at 05:24:46AM +0000, eocene wrote: > Miroslav wrote: > > But, since I started about it here, let me explain. Look here, how my > > dillo brings pages to me currently: > > https://forums.gentoo.org/viewtopic-t-1004014.html#7724054 > > and currently, download and open the mkv files... (So people reading > > later, open the, hopefully, webm files. That's how it was, talking to > > you in the future.) > > I don't think XFT is enabled in your FLTK. That would explain why you > aren't getting DejaVu Sans and the rest... > > > ##################################################################### > > The Homepage is particularly too hard to read for, I guess at least a > > non-insignificant though small percentage (no, not less than a small > > percentage number, it's not insignificant!) of visitors. The background > > must be very light. As soon as it is too dark, the font is not easily > > readable. > > ##################################################################### > > A couple of years ago, I experimented with a different color scheme, but > the other members of the core team weren't enthusiastic about it, so I > never made the change. Example: http://www.dillo.org/test/dillo2.html > Pls, pls. dillo devs, allow that color scheme. If that were the default, I wouldn't have so much difficulties. And surely others!, as I wrote. Why do large associations, businesses, others, never, almost never have unreadable pages?, never experiment with colors --such as, worth mentioning, some smaller, always only smaller entities, make pages in revert, white on black: which is almost never good, unless you want to exclude readers... Pls. dillo devs, allow that color scheme. Thank you! > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

April 4, 2015

Secure: yes, Though Features Missing; and Bugs

by eocene＠gmx.com

Miroslav wrote: > But, since I started about it here, let me explain. Look here, how my > dillo brings pages to me currently: > https://forums.gentoo.org/viewtopic-t-1004014.html#7724054 > and currently, download and open the mkv files... (So people reading > later, open the, hopefully, webm files. That's how it was, talking to > you in the future.) I don't think XFT is enabled in your FLTK. That would explain why you aren't getting DejaVu Sans and the rest... > ##################################################################### > The Homepage is particularly too hard to read for, I guess at least a > non-insignificant though small percentage (no, not less than a small > percentage number, it's not insignificant!) of visitors. The background > must be very light. As soon as it is too dark, the font is not easily > readable. > ##################################################################### A couple of years ago, I experimented with a different color scheme, but the other members of the core team weren't enthusiastic about it, so I never made the change. Example: http://www.dillo.org/test/dillo2.html

April 4, 2015

patch: provide a redirection-blocked page

by eocene＠gmx.com

I was in the mood to make the use of domainrc more pleasant. Having to check the terminal for redirection-denied MSGs is no fun, and sometimes I imagine that I'm the only person who uses it due to its...limited friendliness. Patch attached.

April 4, 2015

Documentation fixes: autolinking

by onepoint＠starurchin.org

I wrote: > Jorge Arellano Cid wrote: > > > On Mon, Mar 16, 2015 at 03:28:43PM +0000, Jeremy Henty wrote: > > > > > > Three small patches that fix autolinking errors in the documentation. > > > The first two escape the autolinking syntax in a few places where it > > > was not intended to be a link. The third fixes a few places where a > > > link was intended but the autolink syntax was not quite right. > > > > > > http://starurchin.org/dillo/patch/doxygen-escape-hash-characters.html > > > http://starurchin.org/dillo/patch/doxygen-escape-double-colons.html > > > http://starurchin.org/dillo/patch/doxygen-fix-simple-name-refs.html > > > > > > Comments are welcome. > > > > > > If these are OK I can push them myself as I have write permission. > > > (It's actually easier for me to do it myself because Mercurial Queues > > > does not notice when the remote repository has a patch that is > > > identical to a patch in its queue and generates spurious errors.) > > > > +1. > > > > Just not sure about the last one. I don't know whether it > > changes the intended semantic for human readers. > > I think it actually corrects the semantics. An initial '::' means > resolve the name in the top namespace, not the current one, but the > class names used in the docs are relative to dw/lout. So I think the > patch does the right thing. Bump! Is it OK for me to push these or is more discussion needed? Regards, Jeremy Henty

April 4, 2015

Secure: yes, Though Features Missing; and Bugs

by miroslav.rovis1＠zg.ht.hr

( I already wrote this entire message, and only then noticed eocene didn't send this to dillo-dev but only to me. But I now have to, All written. Can't correct that now. ) On Fri, Apr 03, 2015 at 08:14:36PM +0000, eocene wrote: > miroslav.rovis1 wrote: > > ukrainian at uabox ~ $ Domain: Default accept. > > By the way, if you're interested in making your browsing more secure, > you could modify your domainrc file not to have 'accept' as its default > rule. Let me first reply to this message. I really wish to start viewing dillo more comfortably first, so this will wait. But, since I started about it here, let me explain. Look here, how my dillo brings pages to me currently: https://forums.gentoo.org/viewtopic-t-1004014.html#7724054 and currently, download and open the mkv files... (So people reading later, open the, hopefully, webm files. That's how it was, talking to you in the future.) Those mkv files will, hopefully, soon be replaced with the HTML5 compliant webm files. So if opened those, that's how it shows currently. I was only able to use dillo after reverting my 1024x768 capable old monitor, to 800x600, in another display in X (:1.0 in, say, ffmpeg command line), else, I would have gone blind from effort to read. And I still have difficulty reading some of the pages. ##################################################################### The Homepage is particularly too hard to read for, I guess at least a non-insignificant though small percentage (no, not less than a small percentage number, it's not insignificant!) of visitors. The background must be very light. As soon as it is too dark, the font is not easily readable. ##################################################################### I'm not at poor-accessibility eyesight yet, I don't have problems with most of pages. I really don't. Pls. take notice of this claim of mine and value the outlined paragraph with respect to that claim! I hope this will help dillo homepage become more readable. So, first I really need the fonts, and will follow your kind advice, eocene, on the fonts, as soon as I find more free time. domainrc is great thing to try to sort too, but the other issue is urgent. Pls allow more time for me to reply to your other mail (I got two mails of kind advice from eocene. Can't go online (the SourceForge archive) to see if my bad provider and bad regime filtered some emails out from dillo-dev. Busy elsewhere. -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

April 3, 2015

Secure: yes, Though Features Missing; and Bugs

by eocene＠gmx.com

Miroslav wrote: > ukrainian at uabox /Cmn/mr $ fc-list : family | cut -d ',' -f 2 | sort | egrep 'DejaVu Sans|URW Chancery L|DejaVu Sans|DejaVu Sans Mono' > DejaVu Sans > DejaVu Sans Condensed > DejaVu Sans Light > DejaVu Sans Mono > URW Chancery L > ukrainian at uabox /Cmn/mr $ > ukrainian at uabox /Cmn/mr $ > > it's obvious that I got all the default fonts. > > And yet the fonts are not used by dillo for some reason. If you go to dw/fltkplatform.cc and, in FltkFont::initSystemFonts(), remove the leading underscore in _MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", to get MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", and recompile, what does dillo say when you run it?

April 3, 2015

Secure: yes, Though Features Missing; and Bugs

by miroslav.rovis1＠zg.ht.hr

( This message, if it arrives, will be placed almost correctly in the thread, thanks to Dennis having helped me previously, I have not received any of the messages from the list; it's the bad provider and regime. If this, or any later message of mine doesn't arrive to dillo-dev list, pls remember I promised I would post, what doesn't show publically at SourceForge, on Gentoo Forums, under: Google - can not open any link - malware ?? https://forums.gentoo.org/viewtopic-t-912056-start-25.html around, or shortly after, the time that it would be expected at SourceForge. I apologize for this inconvenience. ) To show difficulties/buggish behavior/my lack of understanding (whatever the issue is, a bug or my ignorance), I'll start dillo from the command line: ukrainian at uabox ~ $ dillo & [2] 26348 ukrainian at uabox ~ $ Domain: Default accept. dillo_dns_init: Here we go! (threaded) Disabling cookies. ** WARNING **: preferred sans-serif font "DejaVu Sans" not found. ** WARNING **: preferred serif font "DejaVu Serif" not found. ** WARNING **: preferred monospace font "DejaVu Sans Mono" not found. ** WARNING **: preferred cursive font "URW Chancery L" not found. ** WARNING **: preferred fantasy font "DejaVu Sans" not found. Nav_open_url: new url='about:splash' And yet the fonts are there. I know I was able to find them. Have to remember how. Looking up: http://www.dillo.org/FAQ.html#q27 and pasting: Q: Why isn't Dillo3 finding the font that I set? fltk-1.3 is somewhat more restricted in its use of font names than fltk2 was. Please try the fc-list command as shown in the current dillorc configuration file to find the right form of the fontname to use. So, ukrainian at uabox ~ $ fc-list gives me too long list of fonts, I'll show it greeped for only DejaVu and URW, for brevity: ukrainian at uabox ~ $ fc-list | egrep 'URW|DejaVu' /usr/share/fonts/dejavu/DejaVuSerif-Bold.ttf: DejaVu Serif:style=Bold /usr/share/fonts/dejavu/DejaVuSerif-Italic.ttf: DejaVu Serif:style=Italic /usr/share/fonts/urw-fonts/p052004l.pfb: URW Palladio L:style=Bold /usr/share/fonts/urw-fonts/a010015l.pfb: URW Gothic L:style=Demi /usr/share/fonts/dejavu/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans Mono:style=Bold Oblique /usr/share/fonts/dejavu/DejaVuSansCondensed-Oblique.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Oblique,Oblique /usr/share/fonts/dejavu/DejaVuSansCondensed-Bold.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold,Bold /usr/share/fonts/dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book /usr/share/fonts/urw-fonts/z003034l.pfb: URW Chancery L:style=Medium Italic /usr/share/fonts/urw-fonts/p052024l.pfb: URW Palladio L:style=Bold Italic /usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold /usr/share/fonts/urw-fonts/p052003l.pfb: URW Palladio L:style=Roman /usr/share/fonts/dejavu/DejaVuSans.ttf: DejaVu Sans:style=Book /usr/share/fonts/urw-fonts/p052023l.pfb: URW Palladio L:style=Italic /usr/share/fonts/urw-fonts/b018015l.pfb: URW Bookman L:style=Demi Bold /usr/share/fonts/urw-fonts/a010013l.pfb: URW Gothic L:style=Book /usr/share/fonts/dejavu/DejaVuSerifCondensed-BoldItalic.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed Bold Italic,Bold Italic /usr/share/fonts/dejavu/DejaVuSerifCondensed-Bold.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed Bold,Bold /usr/share/fonts/dejavu/DejaVuSerif.ttf: DejaVu Serif:style=Book /usr/share/fonts/dejavu/DejaVuSansMono-Oblique.ttf: DejaVu Sans Mono:style=Oblique /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf: DejaVu Sans:style=Bold /usr/share/fonts/urw-fonts/b018012l.pfb: URW Bookman L:style=Light /usr/share/fonts/dejavu/DejaVuSerifCondensed.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed,Book /usr/share/fonts/urw-fonts/a010033l.pfb: URW Gothic L:style=Book Oblique /usr/share/fonts/urw-fonts/b018032l.pfb: URW Bookman L:style=Light Italic /usr/share/fonts/dejavu/DejaVuSerifCondensed-Italic.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed Italic,Italic /usr/share/fonts/dejavu/DejaVuSansCondensed.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed,Book /usr/share/fonts/dejavu/DejaVuSerif-BoldItalic.ttf: DejaVu Serif:style=Bold Italic /usr/share/fonts/dejavu/DejaVuSans-ExtraLight.ttf: DejaVu Sans,DejaVu Sans Light:style=ExtraLight /usr/share/fonts/urw-fonts/a010035l.pfb: URW Gothic L:style=Demi Oblique /usr/share/fonts/dejavu/DejaVuSansCondensed-BoldOblique.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold Oblique,Bold Oblique /usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf: DejaVu Sans:style=Oblique /usr/share/fonts/urw-fonts/b018035l.pfb: URW Bookman L:style=Demi Bold Italic /usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf: DejaVu Sans:style=Bold Oblique In other words, the fonts that dillo complained it could not find, are there: If I look up in the ".dillo/dillorc #------------------------------------------------------------------------- # RENDERING SECTION #------------------------------------------------------------------------- # Default fonts: # # If FLTK has been configured with Xft enabled (the default), you can use # scalable fonts such as DejaVu or Liberation (try running # "fc-list : family | cut -d ',' -f 2 | sort"). #font_serif="DejaVu Serif" #font_sans_serif="DejaVu Sans" #font_cursive="URW Chancery L" #font_fantasy="DejaVu Sans" #font_monospace="DejaVu Sans Mono" # and run the suggested commands, except adding a little, to make shorter message/post, ukrainian at uabox /Cmn/mr $ fc-list : family | cut -d ',' -f 2 | sort | egrep 'DejaVu Sans|URW Chancery L|DejaVu Sans|DejaVu Sans Mono' DejaVu Sans DejaVu Sans Condensed DejaVu Sans Light DejaVu Sans Mono URW Chancery L ukrainian at uabox /Cmn/mr $ ukrainian at uabox /Cmn/mr $ it's obvious that I got all the default fonts. And yet the fonts are not used by dillo for some reason. For the current time, I think I exposed the issue. I don't have much idea what I am missing, or whether it this is actually a bug. -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

April 3, 2015

unicode combining chars and PRE

by eocene＠gmx.com

Looking at http://doc.rust-lang.org/1.0.0-beta/book/more-strings.html#indexing-strings and I see that dillo doesn't like combining characters in PRE. Small example attached.

April 3, 2015