Re: "Code Sandwiches"
== Quote from bearophile (bearophileh...@lycos.com)'s article > One of the things the paper says about D scope guards is: "Scope guards do not provide encapsulation". (Rolls eyes.) I feel like this is a "standard" criticism of language features that's code for "I don't like this feature". IIRC they said the same thing about delegates in Java. Without even reading the paper, there are two reasons why this is an idiotic thing to say: 1. D also provides struct destructors, which are a more encapsulated way of accomplishing the same thing. Scope guards are intended for one-off use cases where declaring a type, etc. is just extra overhead and accomplishes nothing. 2. Encapsulation is only a means, not an end in itself. Sometimes people lose sight of this. The end goal is to write correct, efficient, readable, maintainable programs. If increasing encapsulation hurts these goals instead of helping them (as excessive encapsulation as practiced by obsessive-compulsive people does), then it's a Bad Thing.
Re: "Code Sandwiches"
bearophile napisał: > One of the things the paper says about D scope guards is: "Scope guards do > not provide encapsulation". Yep, they don't. So? -- Tomek
Re: "Code Sandwiches"
On 09.03.2011 23:15, bearophile wrote: Despite D is currently not widely used, it's not hard for me to find references about D into computer science papers I find around. This paper is titles "Code Sandwiches", by Matt Elder, Steve Jackson, and Ben Liblit, it discusses D scope guards too (page 7 and several successive pages): http://pages.cs.wisc.edu/~liblit/tr-1647/ One of the things the paper says about D scope guards is: "Scope guards do not provide encapsulation". Indeed, they are not related to encapsulation directly. What they do provide is a convenient way to write exception safe code, with less fuss and bugs. It's a practical "shortcut" feature meant to be used inside of encapsulated entity, not to create or support one. Bye, bearophile -- Dmitry Olshansky
Re: "Code Sandwiches"
"Nick Sabalausky" wrote in message news:il8rmg$176i$1...@digitalmars.com... > > But why is it that academic authors have a chronic inability to release > any form of text without first cramming it into a goddamn PDF of all > things? It's like how my dad tries to email photos by sticking them into a Word document first. WTF's the point? > This is one example of why I despise Adobe's predominance: PDF is fucking > useless for anything but printing, and no one seems to know it. Isn't it > about time the ivory tower learned about Mosaic? The web is more than a > PDF-distribution tool...Really! It is! Welcome to the mid-90's. Sheesh. >
Re: "Code Sandwiches"
"dsimcha" wrote in message news:il8nlh$10c1$1...@digitalmars.com... > == Quote from bearophile (bearophileh...@lycos.com)'s article >> One of the things the paper says about D scope guards is: "Scope guards >> do not > provide encapsulation". > > (Rolls eyes.) I feel like this is a "standard" criticism of language > features > that's code for "I don't like this feature". IIRC they said the same > thing about > delegates in Java. Without even reading the paper, there are two reasons > why this > is an idiotic thing to say: > > 1. D also provides struct destructors, which are a more encapsulated way > of > accomplishing the same thing. Scope guards are intended for one-off use > cases > where declaring a type, etc. is just extra overhead and accomplishes > nothing. > > 2. Encapsulation is only a means, not an end in itself. Sometimes people > lose > sight of this. The end goal is to write correct, efficient, readable, > maintainable programs. If increasing encapsulation hurts these goals > instead of > helping them (as excessive encapsulation as practiced by > obsessive-compulsive > people does), then it's a Bad Thing. Section 5.2 makes it clear that's not what he's trying to say. Although, the second-last sentence of that section is "But [D's scope guards] remain statements, not functions or classes, and thus do not form reusable sandwich encapsulations." Frankly, though, that's true. Of course, they can be used as part of a mechanism for creating a reusable "code sandwich", but by themselves they're not an encapsulation and not intended to be. And he never actually says that that's a bad thing. And if there's any subtext inferring it's a bad thing, then as far as I can tell it's small enough it may as well not even exist. That said, I wouldn't put much stock in the average academic paper anyway. (Although, from what little I read, this one doesn't seem quite as bad as some. It's actually readable by programmers, which is a nice change from the usual. And I didn't notice any blatantly stupid comments either. It doesn't seem to make much of a point, but it does still seem to have value in discussing the concept of "code sandwiches" and enumerating various approaches to them.) But why is it that academic authors have a chronic inability to release any form of text without first cramming it into a goddamn PDF of all things? This is one example of why I despise Adobe's predominance: PDF is fucking useless for anything but printing, and no one seems to know it. Isn't it about time the ivory tower learned about Mosaic? The web is more than a PDF-distribution tool...Really! It is! Welcome to the mid-90's. Sheesh.
Re: "Code Sandwiches"
Am 09.03.2011 22:33, schrieb Nick Sabalausky: > "Nick Sabalausky" wrote in message > news:il8rmg$176i$1...@digitalmars.com... >> >> But why is it that academic authors have a chronic inability to release >> any form of text without first cramming it into a goddamn PDF of all >> things? > > It's like how my dad tries to email photos by sticking them into a Word > document first. WTF's the point? > No it's not. At least PDF is a standard format with free and open viewers on about any platform. And while sticking photos into a Word document is pretty pointless using PDF for papers does make sense. One thing is that papers are usually published in printed form, the PDFs are more or less a by-product of that. Also they're usually written with LaTeX (or something similar) and the obvious (digital) formats to publish stuff written in *TeX are Postscript and PDF - I guess you agree that PDF is preferable, as it can be searched etc ;) You can also export *TeX to HTML, but that'll probably fuck up formatting and formulas. So you'd have to use some LaTeX->HTML converter and clean up stuff afterwards to make sure the formatting is OK, the formulas are like they were intended to be (missing a small detail like a ' or an index or whatever will make a formula unusable) etc.. This may not be a problem for this specific paper (it's only text, sourcecode and some tables I think), but for many other scientific papers it is. That's the reason why they're mostly published as PDFs. Cheers, - Daniel
Re: "Code Sandwiches"
Am 09.03.2011 22:49, schrieb Daniel Gibson: > Am 09.03.2011 22:33, schrieb Nick Sabalausky: >> "Nick Sabalausky" wrote in message >> news:il8rmg$176i$1...@digitalmars.com... >>> >>> But why is it that academic authors have a chronic inability to release >>> any form of text without first cramming it into a goddamn PDF of all >>> things? >> >> It's like how my dad tries to email photos by sticking them into a Word >> document first. WTF's the point? >> > > No it's not. > At least PDF is a standard format with free and open viewers on about any > platform. > And while sticking photos into a Word document is pretty pointless using PDF > for > papers does make sense. > > One thing is that papers are usually published in printed form, the PDFs are > more or less a by-product of that. > Also they're usually written with LaTeX (or something similar) and the obvious > (digital) formats to publish stuff written in *TeX are Postscript and PDF - I > guess you agree that PDF is preferable, as it can be searched etc ;) > You can also export *TeX to HTML, but that'll probably fuck up formatting and > formulas. So you'd have to use some LaTeX->HTML converter and clean up stuff > afterwards to make sure the formatting is OK, the formulas are like they were > intended to be (missing a small detail like a ' or an index or whatever will > make a formula unusable) etc.. > This may not be a problem for this specific paper (it's only text, sourcecode > and some tables I think), but for many other scientific papers it is. > That's the reason why they're mostly published as PDFs. > > Cheers, > > - Daniel One more thing: Published papers will probably be cited by other papers or theses. With PDF this is easier, you can write "XYZ, page 42, l 13" - with HTML pages it's not that easy, you could maybe write "in chapter 3 somewhere in the 5th paragraph" or something like that, but that sucks. Or worse "on the fourth page in the third paragraph" and once a new CMS is used that splits pages differently that is completely meaningless..
Re: "Code Sandwiches"
"Daniel Gibson" wrote in message news:il8t79$2t70$2...@digitalmars.com... > Am 09.03.2011 22:49, schrieb Daniel Gibson: >> Am 09.03.2011 22:33, schrieb Nick Sabalausky: >>> "Nick Sabalausky" wrote in message >>> news:il8rmg$176i$1...@digitalmars.com... But why is it that academic authors have a chronic inability to release any form of text without first cramming it into a goddamn PDF of all things? >>> >>> It's like how my dad tries to email photos by sticking them into a Word >>> document first. WTF's the point? >>> >> >> No it's not. >> At least PDF is a standard format with free and open viewers on about any >> platform. Vaguely free, open and standard. Only in the same sense that swf, doc and docx are free, open and standard. HTML (bad as it may be) still wins here. >> And while sticking photos into a Word document is pretty pointless using >> PDF for >> papers does make sense. >> >> One thing is that papers are usually published in printed form, Still? >> the PDFs are >> more or less a by-product of that. >> Also they're usually written with LaTeX (or something similar) and the >> obvious >> (digital) formats to publish stuff written in *TeX are Postscript and >> PDF - I >> guess you agree that PDF is preferable, as it can be searched etc ;) *Some* PDFs can be searched. >> You can also export *TeX to HTML, but that'll probably fuck up formatting >> and >> formulas. So you'd have to use some LaTeX->HTML converter and clean up >> stuff >> afterwards to make sure the formatting is OK, the formulas are like they >> were >> intended to be (missing a small detail like a ' or an index or whatever >> will >> make a formula unusable) etc.. So after 15 years there still isn't a good Latex->HTML converter? Sounds more like the matter is a lack of interest in using anything other than PDF rather than a lack of a good Latex->HTML converter. >> This may not be a problem for this specific paper (it's only text, >> sourcecode >> and some tables I think), but for many other scientific papers it is. >> That's the reason why they're mostly published as PDFs. >> >> Cheers, >> >> - Daniel > > One more thing: Published papers will probably be cited by other papers or > theses. With PDF this is easier, you can write "XYZ, page 42, l 13" - with > HTML > pages it's not that easy, you could maybe write "in chapter 3 somewhere in > the > 5th paragraph" or something like that, but that sucks. > Or worse "on the fourth page in the third paragraph" and once a new CMS is > used > that splits pages differently that is completely meaningless.. These formal papers are divided into sections and subsections, plus HTML supports links and anchors, and even supports disabled word wrapping if that's really needed, so those are non-issues.
Re: "Code Sandwiches"
Am 09.03.2011 23:38, schrieb Nick Sabalausky: > "Daniel Gibson" wrote in message > news:il8t79$2t70$2...@digitalmars.com... >> Am 09.03.2011 22:49, schrieb Daniel Gibson: >>> Am 09.03.2011 22:33, schrieb Nick Sabalausky: "Nick Sabalausky" wrote in message news:il8rmg$176i$1...@digitalmars.com... > > But why is it that academic authors have a chronic inability to release > any form of text without first cramming it into a goddamn PDF of all > things? It's like how my dad tries to email photos by sticking them into a Word document first. WTF's the point? >>> >>> No it's not. >>> At least PDF is a standard format with free and open viewers on about any >>> platform. > > Vaguely free, open and standard. Only in the same sense that swf, doc and > docx are free, open and standard. HTML (bad as it may be) still wins here. > No, PDF is an ISO standard, swf and doc aren't and docx isn't either, because it doesn't really conform with the OOXML ISO standard.. As mentioned before: there are free and open viewers for PDF for (almost?) all platforms that work reasonably well. Can't say the same about doc(x) or swf.. That HTML is rendered almost the same on different browsers is a pretty recent development as well... Nevertheless HTML doesn't have as much formatting possibilities as LaTeX, especially for formulas, so you'd end up using a lot of images which is suboptimal. (Yeah I know there's MathML, but AFAIK it's not properly supported by all browsers). > >>> And while sticking photos into a Word document is pretty pointless using >>> PDF for >>> papers does make sense. >>> >>> One thing is that papers are usually published in printed form, > > Still? > I think so. And even if they aren't they're formatted like that anyway. > >>> the PDFs are >>> more or less a by-product of that. >>> Also they're usually written with LaTeX (or something similar) and the >>> obvious >>> (digital) formats to publish stuff written in *TeX are Postscript and >>> PDF - I >>> guess you agree that PDF is preferable, as it can be searched etc ;) > > *Some* PDFs can be searched. > Most can, the others are - most probably deliberately - broken. You can do the same with HTML if you want, just use images instead of real text.. > >>> You can also export *TeX to HTML, but that'll probably fuck up formatting >>> and >>> formulas. So you'd have to use some LaTeX->HTML converter and clean up >>> stuff >>> afterwards to make sure the formatting is OK, the formulas are like they >>> were >>> intended to be (missing a small detail like a ' or an index or whatever >>> will >>> make a formula unusable) etc.. > > So after 15 years there still isn't a good Latex->HTML converter? Sounds > more like the matter is a lack of interest in using anything other than PDF > rather than a lack of a good Latex->HTML converter. > I don't know. I think I don't have to tell someone who still uses Firefox2 that people don't have the motivation to try new software all the time just because it may finally be usable ;) > >>> This may not be a problem for this specific paper (it's only text, >>> sourcecode >>> and some tables I think), but for many other scientific papers it is. >>> That's the reason why they're mostly published as PDFs. >>> >>> Cheers, >>> >>> - Daniel >> >> One more thing: Published papers will probably be cited by other papers or >> theses. With PDF this is easier, you can write "XYZ, page 42, l 13" - with >> HTML >> pages it's not that easy, you could maybe write "in chapter 3 somewhere in >> the >> 5th paragraph" or something like that, but that sucks. >> Or worse "on the fourth page in the third paragraph" and once a new CMS is >> used >> that splits pages differently that is completely meaningless.. > > These formal papers are divided into sections and subsections, plus HTML > supports links and anchors, and even supports disabled word wrapping if > that's really needed, so those are non-issues. > If anchors etc are used.. fine. But you can't take that for granted.
Re: "Code Sandwiches"
On 03/09/2011 09:24 PM, dsimcha wrote: 2. Encapsulation is only a means, not an end in itself. Sometimes people lose sight of this. The end goal is to write correct, efficient, readable, maintainable programs. If increasing encapsulation hurts these goals instead of helping them (as excessive encapsulation as practiced by obsessive-compulsive people does), then it's a Bad Thing. Oy, que yes! Denis -- _ vita es estrany spir.wikidot.com
Re: "Code Sandwiches"
On 03/09/2011 10:30 PM, Nick Sabalausky wrote: But why is it that academic authors have a chronic inability to release any form of text without first cramming it into a goddamn PDF of all things? This is one example of why I despise Adobe's predominance: PDF is fucking useless for anything but printing, and no one seems to know it. Isn't it about time the ivory tower learned about Mosaic? The web is more than a PDF-distribution tool...Really! It is! Welcome to the mid-90's. Sheesh. Agreed. Actually, AFAIK, pdf was born as a paper-printing format (ps legacy, in fact). That's why it systematically has white background. (Thank godS, Unbuntu's doc viewer recently got an "inverse video" mode. Unthank gods, white on black is far to be the most legible color combination. Anyway, better than the opposite...) Denis -- _ vita es estrany spir.wikidot.com
Re: "Code Sandwiches"
spir: > (Thank godS, Unbuntu's doc viewer recently got an "inverse video" mode. > Unthank > gods, white on black is far to be the most legible color combination. Anyway, > better than the opposite...) Two of the most important PDF viewrs have an option to change the backgroup color of the pages to the color you want :-) Bye, bearophile
Re: "Code Sandwiches"
On Wednesday 09 March 2011 13:30:27 Nick Sabalausky wrote: > But why is it that academic authors have a chronic inability to release any > form of text without first cramming it into a goddamn PDF of all things? > This is one example of why I despise Adobe's predominance: PDF is fucking > useless for anything but printing, and no one seems to know it. Isn't it > about time the ivory tower learned about Mosaic? The web is more than a > PDF-distribution tool...Really! It is! Welcome to the mid-90's. Sheesh. And what format would you _want_ it in? PDF is _way_ better than having a file for any particular word processor. What else would you pick? HTML? Yuck. How would _that_ be any better than a PDF? These are _papers_ after all, not some web article. They're either written up in a word processor or with latex. Distributing them as PDFs makes perfect sense. And yes, most of these papers are published in print format as their main form of release. You're usually lucky to be able to get a PDF format instead of having to have bought the appropriate magazine or book of papers from a particular conference. - Jonathan M Davis
Re: "Code Sandwiches"
"Jonathan M Davis" wrote in message news:mailman.2409.1299728378.4748.digitalmar...@puremagic.com... > On Wednesday 09 March 2011 13:30:27 Nick Sabalausky wrote: >> But why is it that academic authors have a chronic inability to release >> any >> form of text without first cramming it into a goddamn PDF of all things? >> This is one example of why I despise Adobe's predominance: PDF is fucking >> useless for anything but printing, and no one seems to know it. Isn't it >> about time the ivory tower learned about Mosaic? The web is more than a >> PDF-distribution tool...Really! It is! Welcome to the mid-90's. Sheesh. > > And what format would you _want_ it in? PDF is _way_ better than having a > file > for any particular word processor. What else would you pick? HTML? Yuck. > How > would _that_ be any better than a PDF? These are _papers_ after all, not > some > web article. They're either written up in a word processor or with latex. > Distributing them as PDFs makes perfect sense. They're text. With minor formatting. That alone makes html better. Html is lousy for a lot of things, but formatted text is the one thing it's always been perfectly good at. And frankly I think I'd *rather* go with pretty much any word processing format if the only other option was pdf. Of course, show me a pdf viewer that's actually worth a damn for viewing documents on a PC instead of just printing, and maybe I could be persuaded to not mind so much. So far I've used (as far as I can think of, I know there's been others), Acrobat Reader (which I don't even allow on my computer anymore), the one built into OSX, and FoxIt. > > And yes, most of these papers are published in print format as their main > form > of release. You're usually lucky to be able to get a PDF format instead of > having to have bought the appropriate magazine or book of papers from a > particular conference. > I'm all too well aware how much academics considers us unwashed masses lucky to ever be granted the privilege to so much as glance upon any of their pristine excellence.
Re: "Code Sandwiches"
On Wednesday 09 March 2011 22:18:53 Nick Sabalausky wrote: > "Jonathan M Davis" wrote in message > news:mailman.2409.1299728378.4748.digitalmar...@puremagic.com... > > > On Wednesday 09 March 2011 13:30:27 Nick Sabalausky wrote: > >> But why is it that academic authors have a chronic inability to release > >> any > >> form of text without first cramming it into a goddamn PDF of all things? > >> This is one example of why I despise Adobe's predominance: PDF is > >> fucking useless for anything but printing, and no one seems to know it. > >> Isn't it about time the ivory tower learned about Mosaic? The web is > >> more than a PDF-distribution tool...Really! It is! Welcome to the > >> mid-90's. Sheesh. > > > > And what format would you _want_ it in? PDF is _way_ better than having a > > file > > for any particular word processor. What else would you pick? HTML? Yuck. > > How > > would _that_ be any better than a PDF? These are _papers_ after all, not > > some > > web article. They're either written up in a word processor or with latex. > > Distributing them as PDFs makes perfect sense. > > They're text. With minor formatting. That alone makes html better. Html is > lousy for a lot of things, but formatted text is the one thing it's always > been perfectly good at. And frankly I think I'd *rather* go with pretty > much any word processing format if the only other option was pdf. I'm afraid that I don't understand at all. The only time that I would consider html better than a pdf is if the pdf isn't searchable (and most papers _are_ searchable). And I _definitely_ don't like dealing with whatever word processor format someone happens to be using. PDF is nice and universal. I don't have to worry about whether I have the appropriate fonts or if I even have a program which can read their word processor format of choice. I don't really have any gripes with PDF at all. - Jonathan M Davis
Re: "Code Sandwiches"
"Daniel Gibson" wrote in message news:il90m3$2t70$3...@digitalmars.com... > Am 09.03.2011 23:38, schrieb Nick Sabalausky: >> "Daniel Gibson" wrote in message >> news:il8t79$2t70$2...@digitalmars.com... >>> Am 09.03.2011 22:49, schrieb Daniel Gibson: Am 09.03.2011 22:33, schrieb Nick Sabalausky: > "Nick Sabalausky" wrote in message > news:il8rmg$176i$1...@digitalmars.com... >> >> But why is it that academic authors have a chronic inability to >> release >> any form of text without first cramming it into a goddamn PDF of all >> things? > > It's like how my dad tries to email photos by sticking them into a > Word > document first. WTF's the point? > No it's not. At least PDF is a standard format with free and open viewers on about any platform. >> >> Vaguely free, open and standard. Only in the same sense that swf, doc and >> docx are free, open and standard. HTML (bad as it may be) still wins >> here. >> > > No, PDF is an ISO standard, swf and doc aren't and docx isn't either, > because it > doesn't really conform with the OOXML ISO standard.. > Yea, well, it's still heavily rooted in Adobe. > As mentioned before: there are free and open viewers for PDF for (almost?) > all > platforms that work reasonably well. Reasonably well only as far as viewing pdfs on a pc *ever* works "reasonably well". > Can't say the same about doc(x) or swf.. No argument here. Never been a fan of doc or swf anyway. > That HTML is rendered almost the same on different browsers is a pretty > recent > development as well... They're documents. They have no need for perfectly consistent rendering. Hell, these are exactly the sorts of things html was *created* for. It was *intended* for people to view documents however they want to view them. > Nevertheless HTML doesn't have as much formatting possibilities as LaTeX, > especially for formulas, so you'd end up using a lot of images which is > suboptimal. I don't see what's wrong with using images for formulas. As for other types of formatting, how much does a document (that isn't pretending to be real software or a multimedia "experience") really need? the PDFs are more or less a by-product of that. Also they're usually written with LaTeX (or something similar) and the obvious (digital) formats to publish stuff written in *TeX are Postscript and PDF - I guess you agree that PDF is preferable, as it can be searched etc ;) >> >> *Some* PDFs can be searched. >> > > Most can, the others are - most probably deliberately - broken. > You can do the same with HTML if you want, just use images instead of real > text.. > Yea, you can do the same with html, but nobody ever does. OTOH, I've come across plenty of pdfs with "text" that isn't really text. But I'll grant that's not much of a reason against the content producer choosing pdf, since they're fully capable of choosing to make it searchable. >> You can also export *TeX to HTML, but that'll probably fuck up formatting and formulas. So you'd have to use some LaTeX->HTML converter and clean up stuff afterwards to make sure the formatting is OK, the formulas are like they were intended to be (missing a small detail like a ' or an index or whatever will make a formula unusable) etc.. >> >> So after 15 years there still isn't a good Latex->HTML converter? Sounds >> more like the matter is a lack of interest in using anything other than >> PDF >> rather than a lack of a good Latex->HTML converter. >> > > I don't know. I think I don't have to tell someone who still uses Firefox2 > that > people don't have the motivation to try new software all the time just > because > it may finally be usable ;) > I don't use FF2 because I like it. And I *certainly* don't use it for lack of trying all the alternatives. I have a *huge* amount of interest in a variant of FF3 or SRWare Iron or even IE that gets rid of all the crap that I don't have to deal with in FF2. The problem is, I'm the *only* one that has such interest. >>> >>> One more thing: Published papers will probably be cited by other papers >>> or >>> theses. With PDF this is easier, you can write "XYZ, page 42, l 13" - >>> with >>> HTML >>> pages it's not that easy, you could maybe write "in chapter 3 somewhere >>> in >>> the >>> 5th paragraph" or something like that, but that sucks. >>> Or worse "on the fourth page in the third paragraph" and once a new CMS >>> is >>> used >>> that splits pages differently that is completely meaningless.. >> >> These formal papers are divided into sections and subsections, plus HTML >> supports links and anchors, and even supports disabled word wrapping if >> that's really needed, so those are non-issues. >> > > If anchors etc are used.. fine. But you can't take that for granted. Strawman argument. We're talking about the party that *releases* the do
Re: "Code Sandwiches"
"Jonathan M Davis" wrote in message news:mailman.2411.1299739219.4748.digitalmar...@puremagic.com... > On Wednesday 09 March 2011 22:18:53 Nick Sabalausky wrote: >> "Jonathan M Davis" wrote in message >> news:mailman.2409.1299728378.4748.digitalmar...@puremagic.com... >> >> > On Wednesday 09 March 2011 13:30:27 Nick Sabalausky wrote: >> >> But why is it that academic authors have a chronic inability to >> >> release >> >> any >> >> form of text without first cramming it into a goddamn PDF of all >> >> things? >> >> This is one example of why I despise Adobe's predominance: PDF is >> >> fucking useless for anything but printing, and no one seems to know >> >> it. >> >> Isn't it about time the ivory tower learned about Mosaic? The web is >> >> more than a PDF-distribution tool...Really! It is! Welcome to the >> >> mid-90's. Sheesh. >> > >> > And what format would you _want_ it in? PDF is _way_ better than having >> > a >> > file >> > for any particular word processor. What else would you pick? HTML? >> > Yuck. >> > How >> > would _that_ be any better than a PDF? These are _papers_ after all, >> > not >> > some >> > web article. They're either written up in a word processor or with >> > latex. >> > Distributing them as PDFs makes perfect sense. >> >> They're text. With minor formatting. That alone makes html better. Html >> is >> lousy for a lot of things, but formatted text is the one thing it's >> always >> been perfectly good at. And frankly I think I'd *rather* go with pretty >> much any word processing format if the only other option was pdf. > > I'm afraid that I don't understand at all. The only time that I would > consider > html better than a pdf is if the pdf isn't searchable (and most papers > _are_ > searchable). And I _definitely_ don't like dealing with whatever word > processor > format someone happens to be using. PDF is nice and universal. I don't > have to > worry about whether I have the appropriate fonts or if I even have a > program > which can read their word processor format of choice. I don't really have > any > gripes with PDF at all. > PDF: *Complete* inability to adapt appropriately to the viewing device, *completely* useless page breaks and associated top/bottom page margins in places that have absolutely *no* use for them, no flowing layout, frequent horizontal scrolling, poor (if any) linking, inability for the reader to choose the fonts/etc that *they* find readable. Oh, and ever tried reading one of those pdf's that use a multi-column layout? All of this together makes PDF the #1 worst document format for viewing on a PC. All for what? Increased accuracy the *few* times it ever gets printed? Outside of print-shops, pdf needs to die a horrible death.
Re: "Code Sandwiches"
On Wednesday 09 March 2011 23:15:01 Nick Sabalausky wrote: > "Jonathan M Davis" wrote in message > news:mailman.2411.1299739219.4748.digitalmar...@puremagic.com... > > > On Wednesday 09 March 2011 22:18:53 Nick Sabalausky wrote: > >> "Jonathan M Davis" wrote in message > >> news:mailman.2409.1299728378.4748.digitalmar...@puremagic.com... > >> > >> > On Wednesday 09 March 2011 13:30:27 Nick Sabalausky wrote: > >> >> But why is it that academic authors have a chronic inability to > >> >> release > >> >> any > >> >> form of text without first cramming it into a goddamn PDF of all > >> >> things? > >> >> This is one example of why I despise Adobe's predominance: PDF is > >> >> fucking useless for anything but printing, and no one seems to know > >> >> it. > >> >> Isn't it about time the ivory tower learned about Mosaic? The web is > >> >> more than a PDF-distribution tool...Really! It is! Welcome to the > >> >> mid-90's. Sheesh. > >> > > >> > And what format would you _want_ it in? PDF is _way_ better than > >> > having a > >> > file > >> > for any particular word processor. What else would you pick? HTML? > >> > Yuck. > >> > How > >> > would _that_ be any better than a PDF? These are _papers_ after all, > >> > not > >> > some > >> > web article. They're either written up in a word processor or with > >> > latex. > >> > Distributing them as PDFs makes perfect sense. > >> > >> They're text. With minor formatting. That alone makes html better. Html > >> is > >> lousy for a lot of things, but formatted text is the one thing it's > >> always > >> been perfectly good at. And frankly I think I'd *rather* go with pretty > >> much any word processing format if the only other option was pdf. > > > > I'm afraid that I don't understand at all. The only time that I would > > consider > > html better than a pdf is if the pdf isn't searchable (and most papers > > _are_ > > searchable). And I _definitely_ don't like dealing with whatever word > > processor > > format someone happens to be using. PDF is nice and universal. I don't > > have to > > worry about whether I have the appropriate fonts or if I even have a > > program > > which can read their word processor format of choice. I don't really have > > any > > gripes with PDF at all. > > PDF: *Complete* inability to adapt appropriately to the viewing device, > *completely* useless page breaks and associated top/bottom page margins in > places that have absolutely *no* use for them, no flowing layout, frequent > horizontal scrolling, poor (if any) linking, inability for the reader to > choose the fonts/etc that *they* find readable. Oh, and ever tried reading > one of those pdf's that use a multi-column layout? All of this together > makes PDF the #1 worst document format for viewing on a PC. All for what? > Increased accuracy the *few* times it ever gets printed? Outside of > print-shops, pdf needs to die a horrible death. LOL. It's _supposed_ to have a fixed look. That's part of what's so wonderful about it. You _know_ that it will look right every time. I think that it's quite clear that we're never going to see eye-to-eye on this one. - Jonathan M Davis
Re: "Code Sandwiches"
On 03/10/2011 08:15 AM, Nick Sabalausky wrote: "Jonathan M Davis" wrote in message news:mailman.2411.1299739219.4748.digitalmar...@puremagic.com... On Wednesday 09 March 2011 22:18:53 Nick Sabalausky wrote: "Jonathan M Davis" wrote in message news:mailman.2409.1299728378.4748.digitalmar...@puremagic.com... On Wednesday 09 March 2011 13:30:27 Nick Sabalausky wrote: But why is it that academic authors have a chronic inability to release any form of text without first cramming it into a goddamn PDF of all things? This is one example of why I despise Adobe's predominance: PDF is fucking useless for anything but printing, and no one seems to know it. Isn't it about time the ivory tower learned about Mosaic? The web is more than a PDF-distribution tool...Really! It is! Welcome to the mid-90's. Sheesh. And what format would you _want_ it in? PDF is _way_ better than having a file for any particular word processor. What else would you pick? HTML? Yuck. How would _that_ be any better than a PDF? These are _papers_ after all, not some web article. They're either written up in a word processor or with latex. Distributing them as PDFs makes perfect sense. They're text. With minor formatting. That alone makes html better. Html is lousy for a lot of things, but formatted text is the one thing it's always been perfectly good at. And frankly I think I'd *rather* go with pretty much any word processing format if the only other option was pdf. I'm afraid that I don't understand at all. The only time that I would consider html better than a pdf is if the pdf isn't searchable (and most papers _are_ searchable). And I _definitely_ don't like dealing with whatever word processor format someone happens to be using. PDF is nice and universal. I don't have to worry about whether I have the appropriate fonts or if I even have a program which can read their word processor format of choice. I don't really have any gripes with PDF at all. PDF: *Complete* inability to adapt appropriately to the viewing device, *completely* useless page breaks and associated top/bottom page margins in places that have absolutely *no* use for them, no flowing layout, frequent horizontal scrolling, poor (if any) linking, inability for the reader to choose the fonts/etc that *they* find readable. Oh, and ever tried reading one of those pdf's that use a multi-column layout? All of this together makes PDF the #1 worst document format for viewing on a PC. All for what? Increased accuracy the *few* times it ever gets printed? Outside of print-shops, pdf needs to die a horrible death. Agreed. pdf (or maybe rather the more powerful ps) should be an end-of-chain format just before printing. Delivering pdf docs for anyhting else makes no sense. pdf is a printing format (a poor one, according to typo professional, please ask); nothing else. Also, nowadays, it's no more necessary to use ps or pdf to get (correct) printing. Nearly anything can be composed and printed as is. An exception may be complex math formulas (in latex indeed). Even then, one can precompose them into plain graphics. Denis -- _ vita es estrany spir.wikidot.com
Re: "Code Sandwiches"
On 03/10/2011 01:58 AM, bearophile wrote: spir: (Thank godS, Unbuntu's doc viewer recently got an "inverse video" mode. Unthank gods, white on black is far to be the most legible color combination. Anyway, better than the opposite...) Two of the most important PDF viewrs have an option to change the backgroup color of the pages to the color you want :-) Would you tell me which ones (off list). Denis -- _ vita es estrany spir.wikidot.com
Re: "Code Sandwiches"
On Thu, 10 Mar 2011 02:15:01 -0500, Nick Sabalausky wrote: > PDF: *Complete* inability to adapt appropriately to the viewing device, > *completely* useless page breaks and associated top/bottom page margins > in places that have absolutely *no* use for them, no flowing layout, > frequent horizontal scrolling, poor (if any) linking, inability for the > reader to choose the fonts/etc that *they* find readable. Oh, and ever > tried reading one of those pdf's that use a multi-column layout? All of > this together makes PDF the #1 worst document format for viewing on a > PC. All for what? Increased accuracy the *few* times it ever gets > printed? Outside of print-shops, pdf needs to die a horrible death. I completely disagree. But then again, you would probably label me as one of the "ivory tower academic authors". ;) PDF ensures a consistent look across different platforms and viewers, because the layout is fixed and fonts can be embedded. This is especially important when the document contains formulas. Embedding formulas as images isn't really an option, because you want them to be in the same font as (or a font that looks good with) the document's main font. This is generally not possible with HTML, because you never know which fonts are installed on the target computer. (Yes, there's the @font-face CSS thingy, but AFAIK it's rarely used due to font licensing issues.) As I see it, the only viable option for embedding math in HTML is to use MathML. Unfortunately, that's generally not supported in any of the current web browsers, though most of them will support it in their upcoming releases (IE being the exception, I think). It remains to be seen how good the MathML rendering engines turn out to be. (You think badly rendered text is hard to read? Badly rendered formulas are *much* worse.) Anyway, besides ensuring good-looking formulas, a fixed layout means that you are in full control over other typesetting issues such as hyphenation. Yes, you can do that automatically with JavaScript, but you can never be sure of the result. And finally, I have yet to see any web browser or word processor that even comes close to LaTeX with regards to typesetting quality. Show me a PDF file created by LaTeX and a PDF version of a Word document, and I'm pretty sure I can tell at a glance which is which. I don't understand your big gripe with PDF readers either. Maybe Adobe just makes a crappy one? I use the one that comes with the GNOME desktop, Evince, and it works perfectly. (It's open source, too!) As we speak I have it open on a 1422-page PDF document, and I can scroll without any lag, search for text (and math, even), and basically do anything I can in a web reader. -Lars
Re: "Code Sandwiches"
Am 10.03.2011 11:46, schrieb Lars T. Kyllingstad: I don't understand your big gripe with PDF readers either. Maybe Adobe just makes a crappy one? I use the one that comes with the GNOME desktop, Evince, and it works perfectly. (It's open source, too!) As we speak I have it open on a 1422-page PDF document, and I can scroll without any lag, search for text (and math, even), and basically do anything I can in a web reader. -Lars One thing I find annoying when viewing PDFs (and this is especially true for academic papers) is that big margins (on left and right) often prevent me from seeing two pages at once at a reasonable text size. Also better support for annotations and such would be great (but HTML doesn't have this either). Adobe Acrobat (not the free reader) supports creating some kind of annotations, but most free readers don't and if they do it's in a proprietary format and it's generally not a very pleasant experience. For example xournal allows you to paint and write onto a PDF, but it can't search PDFs and it can only export the result as a PDF that consists of images, losing searchability.. But in general I don't think having papers as PDFs is such a big deal. Cheers, - Daniel
Re: "Code Sandwiches"
On 3/9/11 11:49 PM, spir wrote: pdf is a printing format (a poor one, according to typo professional, please ask); nothing else. This is rather surprising given that Addison Wesley uses pdf throughout as their publication format. Other publishers I talked to do the same, and so do smaller publishers (including shops such as Kinko's). So yes, I'd be curious. Also, nowadays, it's no more necessary to use ps or pdf to get (correct) printing. Nearly anything can be composed and printed as is. What do you mean by "as is"? An exception may be complex math formulas (in latex indeed). Even then, one can precompose them into plain graphics. You mean raster graphics? That would suck pretty badly. Or instead vector graphics? But then the question remains how you represent the symbols, and you're back to the issue of embedded fonts, at which PDF is quite adept. Andrei
Re: "Code Sandwiches"
On 3/9/11 5:15 PM, bearophile wrote: Despite D is currently not widely used, it's not hard for me to find references about D into computer science papers I find around. This paper is titles "Code Sandwiches", by Matt Elder, Steve Jackson, and Ben Liblit, it discusses D scope guards too (page 7 and several successive pages): http://pages.cs.wisc.edu/~liblit/tr-1647/ One of the things the paper says about D scope guards is: "Scope guards do not provide encapsulation". Bye, bearophile So strange they don't mention Ruby, which has the best code sandwiches ever :-P Sample code (won't work, this is just the idea) def with_lock(some_lock) some_lock.lock yield some_lock.unlock end Usage: with_lock(foo) do # Whatever end This way you get syntactic linkage and encapsulation, but not inevitability (because # Whatever might raise an exception). For that you have to do: def with_lock(some_lock) some_lock.lock yield ensure some_lock.unlock end
Re: "Code Sandwiches"
"Lars T. Kyllingstad" wrote in message news:ilaa5k$2vls$2...@digitalmars.com... > > PDF ensures a consistent look across different platforms and viewers, > because the layout is fixed and fonts can be embedded. That's a significant part of what makes it good for printing and terrible for everything else. > Embedding formulas as images isn't really an option, because you want > them to be in the same font as (or a font that looks good with) the > document's main font. That strikes me as worrying over a trivial detail. Is the formula's font *really*the point, or it is the formula itself? > As I see it, the only viable option for embedding math in HTML is to use > MathML. "Viable" and "perfect" are two very different things. If you feel that the formulas *MUST* be in the same font as the rest, then it sounds like you mean "perfect" not "viable". > Anyway, besides ensuring good-looking formulas, a fixed layout means that > you are in full control over other typesetting issues such as > hyphenation. Again, that *belongs* in the realm of the reader, the reader's machine and the document viewer. This isn't old-school dead-tree media we're talking about here. In printed form, the viewing device/app and the publication format are inherently the exact same thing, so the distinction is irrelevent and presentation details like that may as well be handled by the producer. But with computers, the two things are inherently very different. The bottom line is, viewing a document should work as well as it reasonably can on *anything* it's viewed on, any app, any device, any person. Yes, that might *seem* to indicate letting the producer control every detail, but outside of paper (where there *is* only one "app/device" the document is viewed with) that doesn't work: Obviously, different viewers are going to have different needs, different optimal uses, etc. Is it at all reasonable for the content producer to take into account every viewer/device or even personal preference that it's going to come across, even just in the present, let alone the future? Certainly not (heck, that would be lke the days before device drivers). Is it even conceivably *possible* with PDF? Not remotely. The *only* thing that has the proper information to appropriately format a document is the viewer itself, the device itself, etc. *Not* the content producer. > And finally, I have yet to see any web browser or word processor that > even comes close to LaTeX with regards to typesetting quality. Show me a > PDF file created by LaTeX and a PDF version of a Word document, and I'm > pretty sure I can tell at a glance which is which. > I don't doubt that. But show *me* the same two documents and *if* I can tell them apart I'm pretty sure I could tell that I don't care which is which. Seriously, does anyone without a typesetting background ever even notice such things? > I don't understand your big gripe with PDF readers either. Maybe Adobe > just makes a crappy one? They do. A *very* crappy one. That's why I use FoxIt instead. > I use the one that comes with the GNOME > desktop, Evince, and it works perfectly. (It's open source, too!) As we > speak I have it open on a 1422-page PDF document, and I can scroll > without any lag, search for text (and math, even), and basically do > anything I can in a web reader. > Does it stick page breaks in the middle of a document? Do the page breaks serve *any* useful purpose outside printed form? Can web pages link to specific parts of the document? When the PDF is from a book that has smaller inner margins than outer margins, do the left/right margns keep changing form one page to the next? If you resize the window, can you still read it without introducing horizontal scrolling? If you find the chosen font difficult to read, or you merely prefer a different one, can you change it? Are comparable programs as widespread on mobile devices as web browsers are? Do they integrate well with the mobile device's browser?
Re: "Code Sandwiches"
On 3/10/11 2:22 PM, Nick Sabalausky wrote: "Lars T. Kyllingstad" wrote in message news:ilaa5k$2vls$2...@digitalmars.com... Embedding formulas as images isn't really an option, because you want them to be in the same font as (or a font that looks good with) the document's main font. That strikes me as worrying over a trivial detail. Is the formula's font *really*the point, or it is the formula itself? http://www-cs-faculty.stanford.edu/~uno/cm.html Andrei
Re: "Code Sandwiches"
"Andrei Alexandrescu" wrote in message news:ilbmlp$oq$1...@digitalmars.com... > On 3/10/11 2:22 PM, Nick Sabalausky wrote: >> "Lars T. Kyllingstad" wrote in message >> news:ilaa5k$2vls$2...@digitalmars.com... >>> Embedding formulas as images isn't really an option, because you want >>> them to be in the same font as (or a font that looks good with) the >>> document's main font. >> >> That strikes me as worrying over a trivial detail. Is the formula's font >> *really*the point, or it is the formula itself? > > http://www-cs-faculty.stanford.edu/~uno/cm.html > Those look the same to me. "In fact, the old delta was so ugly, I couldn't stand to write papers using that symbol; now I can't stand to read papers that still do use it." And I thought *I* tended to be particular about things!
Re: "Code Sandwiches"
Thu, 10 Mar 2011 01:18:53 -0500, Nick Sabalausky wrote: > "Jonathan M Davis" wrote in message > news:mailman.2409.1299728378.4748.digitalmar...@puremagic.com... >> On Wednesday 09 March 2011 13:30:27 Nick Sabalausky wrote: >>> But why is it that academic authors have a chronic inability to >>> release any >>> form of text without first cramming it into a goddamn PDF of all >>> things? This is one example of why I despise Adobe's predominance: PDF >>> is fucking useless for anything but printing, and no one seems to know >>> it. Isn't it about time the ivory tower learned about Mosaic? The web >>> is more than a PDF-distribution tool...Really! It is! Welcome to the >>> mid-90's. Sheesh. >> >> And what format would you _want_ it in? PDF is _way_ better than having >> a file >> for any particular word processor. What else would you pick? HTML? >> Yuck. How >> would _that_ be any better than a PDF? These are _papers_ after all, >> not some >> web article. They're either written up in a word processor or with >> latex. Distributing them as PDFs makes perfect sense. > > They're text. With minor formatting. That alone makes html better. Html > is lousy for a lot of things, but formatted text is the one thing it's > always been perfectly good at. And frankly I think I'd *rather* go with > pretty much any word processing format if the only other option was pdf. > > Of course, show me a pdf viewer that's actually worth a damn for viewing > documents on a PC instead of just printing, and maybe I could be > persuaded to not mind so much. So far I've used (as far as I can think > of, I know there's been others), Acrobat Reader (which I don't even > allow on my computer anymore), the one built into OSX, and FoxIt. > > >> And yes, most of these papers are published in print format as their >> main form >> of release. You're usually lucky to be able to get a PDF format instead >> of having to have bought the appropriate magazine or book of papers >> from a particular conference. >> >> > I'm all too well aware how much academics considers us unwashed masses > lucky to ever be granted the privilege to so much as glance upon any of > their pristine excellence. You clearly have no idea what you're talking about. If you want to publish your results in a peer reviewed conference, which is often a requirement for further funding if you happen to depend on it, then you MUST adopt to their guidelines. This paper is a TR, it probably does not even go through a (peer) review process. Usually you're asked to publish your conference paper using a standard document template, but you're not allowed to republish the paper elsewhere. Sometimes you're allowed to republish it on your personal site if you make some changes. Ever read proceedings where every paper uses different formatting? It doesn't look professional. Now, another point against HTML or DOC or something similar is that you can't really tell what it looks like when printed. I tried to manually write a paper once, but it just didn't work. Also one of the biggest problems is that there's a maximum number of pages allowed. Extra pages cost money due to printing costs. With HTML or DOC you can't be sure how the system that prints the paper organizes all figures and line wrapping. Usually it fails and you get bad quality. You should also take a look at this wrt html http://en.wikipedia.org/wiki/Justification_(typesetting)
Re: "Code Sandwiches"
"retard" wrote in message news:ilbo57$31ie$1...@digitalmars.com... > Thu, 10 Mar 2011 01:18:53 -0500, Nick Sabalausky wrote: > >> "Jonathan M Davis" wrote in message >> news:mailman.2409.1299728378.4748.digitalmar...@puremagic.com... >>> On Wednesday 09 March 2011 13:30:27 Nick Sabalausky wrote: But why is it that academic authors have a chronic inability to release any form of text without first cramming it into a goddamn PDF of all things? This is one example of why I despise Adobe's predominance: PDF is fucking useless for anything but printing, and no one seems to know it. Isn't it about time the ivory tower learned about Mosaic? The web is more than a PDF-distribution tool...Really! It is! Welcome to the mid-90's. Sheesh. >>> >>> And what format would you _want_ it in? PDF is _way_ better than having >>> a file >>> for any particular word processor. What else would you pick? HTML? >>> Yuck. How >>> would _that_ be any better than a PDF? These are _papers_ after all, >>> not some >>> web article. They're either written up in a word processor or with >>> latex. Distributing them as PDFs makes perfect sense. >> >> They're text. With minor formatting. That alone makes html better. Html >> is lousy for a lot of things, but formatted text is the one thing it's >> always been perfectly good at. And frankly I think I'd *rather* go with >> pretty much any word processing format if the only other option was pdf. >> >> Of course, show me a pdf viewer that's actually worth a damn for viewing >> documents on a PC instead of just printing, and maybe I could be >> persuaded to not mind so much. So far I've used (as far as I can think >> of, I know there's been others), Acrobat Reader (which I don't even >> allow on my computer anymore), the one built into OSX, and FoxIt. >> >> >>> And yes, most of these papers are published in print format as their >>> main form >>> of release. You're usually lucky to be able to get a PDF format instead >>> of having to have bought the appropriate magazine or book of papers >>> from a particular conference. >>> >>> >> I'm all too well aware how much academics considers us unwashed masses >> lucky to ever be granted the privilege to so much as glance upon any of >> their pristine excellence. > > You clearly have no idea what you're talking about. If you want to > publish your results in a peer reviewed conference, which is often a > requirement for further funding if you happen to depend on it, then you > MUST adopt to their guidelines. This paper is a TR, it probably does not > even go through a (peer) review process. > If so, then that paper doesn't need to be restricted to PDF. But regardless, my complaints about PDF usually being the only option were directed at academic papers in general, not just this particular one. > Usually you're asked to publish your conference paper using a standard > document template, but you're not allowed to republish the paper > elsewhere. Oh, I see. That makes it perfectly clear that the academic world is *not* interested in restricting access to information. After all, what could possibly be more open and free than being required to send your work to an obscure publisher with minimal visibility who then says you can't redistribute your own work to a wider audience? Or maybe it's not about restricting access to information at all - maybe they're just stupid and can't see what's happening. Could that be it? Or is it arbitrarily-restricted access? > Ever read proceedings where every paper uses > different formatting? It doesn't look professional. > I never said that a collection of works shouldn't be able to use a consistent style for what's contained within. I was only talking about internet distribution of individual articles. > Now, another point against HTML or DOC or something similar is that you > can't really tell what it looks like when printed. How often do people print a document from the web to read it? And as for mass-printing to distrubute in hardcopy, I've been saying from the start that PDF (AFAIK) is fine for printing. > Also one of the biggest > problems is that there's a maximum number of pages allowed. Extra pages > cost money due to printing costs. With HTML or DOC you can't be sure how > the system that prints the paper organizes all figures and line wrapping. > Usually it fails and you get bad quality. Since when are PDF and HTML mutually exclusive? > You should also take a look at > this wrt html http://en.wikipedia.org/wiki/Justification_(typesetting) I'm familiar with justified text.
Re: "Code Sandwiches"
On Thu, 10 Mar 2011 17:22:53 -0500, Nick Sabalausky wrote: > "Lars T. Kyllingstad" wrote in message > news:ilaa5k$2vls$2...@digitalmars.com... >> >> PDF ensures a consistent look across different platforms and viewers, >> because the layout is fixed and fonts can be embedded. > > That's a significant part of what makes it good for printing and > terrible for everything else. > > >> Embedding formulas as images isn't really an option, because you want >> them to be in the same font as (or a font that looks good with) the >> document's main font. > > That strikes me as worrying over a trivial detail. Is the formula's font > *really*the point, or it is the formula itself? > > >> As I see it, the only viable option for embedding math in HTML is to >> use MathML. > > "Viable" and "perfect" are two very different things. If you feel that > the formulas *MUST* be in the same font as the rest, then it sounds like > you mean "perfect" not "viable". > > >> Anyway, besides ensuring good-looking formulas, a fixed layout means >> that you are in full control over other typesetting issues such as >> hyphenation. > > Again, that *belongs* in the realm of the reader, the reader's machine > and the document viewer. This isn't old-school dead-tree media we're > talking about here. In printed form, the viewing device/app and the > publication format are inherently the exact same thing, so the > distinction is irrelevent and presentation details like that may as well > be handled by the producer. But with computers, the two things are > inherently very different. > > The bottom line is, viewing a document should work as well as it > reasonably can on *anything* it's viewed on, any app, any device, any > person. Yes, that might *seem* to indicate letting the producer control > every detail, but outside of paper (where there *is* only one > "app/device" the document is viewed with) that doesn't work: Obviously, > different viewers are going to have different needs, different optimal > uses, etc. Is it at all reasonable for the content producer to take into > account every viewer/device or even personal preference that it's going > to come across, even just in the present, let alone the future? > Certainly not (heck, that would be lke the days before device drivers). > Is it even conceivably *possible* with PDF? Not remotely. The *only* > thing that has the proper information to appropriately format a document > is the viewer itself, the device itself, etc. *Not* the content > producer. > > >> And finally, I have yet to see any web browser or word processor that >> even comes close to LaTeX with regards to typesetting quality. Show me >> a PDF file created by LaTeX and a PDF version of a Word document, and >> I'm pretty sure I can tell at a glance which is which. >> >> > I don't doubt that. But show *me* the same two documents and *if* I can > tell them apart I'm pretty sure I could tell that I don't care which is > which. Seriously, does anyone without a typesetting background ever even > notice such things? Based on your above comments, I get the feeling that you don't find typography important at all. But typography is at least as important as any other design decision, and most people do care about design. If you create a web site for some company, you want to design it so it looks professional and is easy to use. If I write a scientific paper, I want it to look professional and be easy to read. And although you may not have a conscious opinion about typography, your eyes and brain certainly do. Try reading 20 or 30 pages worth of heavy material, perhaps interspersed with a bunch of mathematical formulas here and there, as rendered by a web browser. I guarantee you, your eyes and brain will be a lot more exhausted than they would have been if the document were professionally typeset. I wish the designers of web sites and browsers would pay more attention to typesetting issues and spend less time on bloating the web with Flash animations and JavaScript misfeatures. >> I don't understand your big gripe with PDF readers either. Maybe Adobe >> just makes a crappy one? > > They do. A *very* crappy one. That's why I use FoxIt instead. > > >> I use the one that comes with the GNOME desktop, Evince, and it works >> perfectly. (It's open source, too!) As we speak I have it open on a >> 1422-page PDF document, and I can scroll without any lag, search for >> text (and math, even), and basically do anything I can in a web reader. >> >> > Does it stick page breaks in the middle of a document? Do the page > breaks serve *any* useful purpose outside printed form? Can web pages > link to specific parts of the document? When the PDF is from a book that > has smaller inner margins than outer margins, do the left/right margns > keep changing form one page to the next? If you resize the window, can > you still read it without introducing horizontal scrolling? If you find > the chosen font difficult to
Re: "Code Sandwiches"
On Thu, 10 Mar 2011 18:43:43 -0500, Nick Sabalausky wrote: > "Andrei Alexandrescu" wrote in message > news:ilbmlp$oq$1...@digitalmars.com... >> On 3/10/11 2:22 PM, Nick Sabalausky wrote: >>> "Lars T. Kyllingstad" wrote in message >>> news:ilaa5k$2vls$2...@digitalmars.com... Embedding formulas as images isn't really an option, because you want them to be in the same font as (or a font that looks good with) the document's main font. >>> >>> That strikes me as worrying over a trivial detail. Is the formula's >>> font *really*the point, or it is the formula itself? >> >> http://www-cs-faculty.stanford.edu/~uno/cm.html >> >> > Those look the same to me. A tiny difference in one symbol, for sure, but in a document with thousands and thousands of symbols, such small differences add up and can impact both reading speed and eye strain. > "In fact, the old delta was so ugly, I couldn't stand to write papers > using that symbol; now I can't stand to read papers that still do use > it." > > And I thought *I* tended to be particular about things! Well, Knuth is the designer of TeX, so it's not too surprising that he has opinions about such details. :) -Lars
Re: "Code Sandwiches"
"Lars T. Kyllingstad" wrote in message news:ilcmaf$19dg$1...@digitalmars.com... > > Based on your above comments, I get the feeling that you don't find > typography important at all. But typography is at least as important as > any other design decision, and most people do care about design. > I wouldn't say I find it to be *zero* importance, I just find it to be of much less importance than UI. And the UI is something I find all PDF readers I've tried to be severely deficient in compared to web browsers (heavily animated sites notwithstanding). And I really think those UI issues have more to do with the nature of PDF than just the quality of the readers. > > I wish the designers of web sites and browsers would pay more attention > to typesetting issues and spend less time on bloating the web with Flash > animations and JavaScript misfeatures. > That I can agree with. I'd *much* rather have a slightly better font and typesetting than flashing, flying, spinning bullcrap. Heck, I'd rather have *worse* fonts and typesetting than Flash/JS misfeatures :) > And please note that I'm not saying PDF is perfect for everything. > Actually, I agree with you that the only thing it is *perfect* for is > printing. Right. I realize that. > But it *is* preferable over HTML in some situations, and > scientific/technical literature is one of those. Novels are another > example. > Well, I'd much prefer html for any of those. I *really* *really* hate trying to read anything in a pdf viewer. I'm actually very surprised that anyone finds it practical. > If someone comes up with an alternative format for on-screen document > reading that does away with obsolete artifacts of printed media, such as > page breaks, odd/even page margins, etc. and has better hyperlinking > capabilities than PDF, but still lets you embed fonts and have full > control over other typesetting issues, I'd be happy to use it. > > Heck, web browsers with decent typesetting engines would be a *huge* step > in the right direction. I'd be all for that stuff as well. Heck, I'm normally one of the first people to agree that HTML, CSS and web browsers have serious problems. But at least I can get by with them (thanks largely to NoScript) as opposed to pdf which I find to be nearly intolerable. I guess there's two good things I can say about pdf's and pdf viewers though: There's rarely any idiotic scripted or multimedia nonsense, and it's not as hard to find pdf viewers that actually obey my system's visual settings.
Re: "Code Sandwiches"
On 03/11/2011 09:25 AM, Lars T. Kyllingstad wrote: Based on your above comments, I get the feeling that you don't find typography important at all. But typography is at least as important as any other design decision, and most people do care about design. If you create a web site for some company, you want to design it so it looks professional and is easy to use. If I write a scientific paper, I want it to look professional and be easy to read. And although you may not have a conscious opinion about typography, your eyes and brain certainly do. Try reading 20 or 30 pages worth of heavy material, perhaps interspersed with a bunch of mathematical formulas here and there, as rendered by a web browser. I guarantee you, your eyes and brain will be a lot more exhausted than they would have been if the document were professionally typeset. I wish the designers of web sites and browsers would pay more attention to typesetting issues and spend less time on bloating the web with Flash animations and JavaScript misfeatures. I do agree. I also wish -- something much easier to do -- they would care for our nerval systems & stop saturating them with non-information (white backgrounds). Denis -- _ vita es estrany spir.wikidot.com
Re: "Code Sandwiches"
On 3/11/11 11:30 AM, spir wrote: I do agree. I also wish -- something much easier to do -- they would care for our nerval systems & stop saturating them with non-information (white backgrounds). Is there any scientific data to back this assumption? David
Re: "Code Sandwiches"
On 3/11/11 5:21 AM, David Nadlinger wrote: On 3/11/11 11:30 AM, spir wrote: I do agree. I also wish -- something much easier to do -- they would care for our nerval systems & stop saturating them with non-information (white backgrounds). Is there any scientific data to back this assumption? David Paper has white background, which worked quite well for it. Andrei
Re: "Code Sandwiches"
On 3/11/11 4:35 PM, Andrei Alexandrescu wrote: On 3/11/11 5:21 AM, David Nadlinger wrote: On 3/11/11 11:30 AM, spir wrote: I do agree. I also wish -- something much easier to do -- they would care for our nerval systems & stop saturating them with non-information (white backgrounds). Is there any scientific data to back this assumption? David Paper has white background, which worked quite well for it. Andrei Yes, but I think spir meant it the other way round… David
Re: "Code Sandwiches"
On Friday 11 March 2011 07:35:09 Andrei Alexandrescu wrote: > On 3/11/11 5:21 AM, David Nadlinger wrote: > > On 3/11/11 11:30 AM, spir wrote: > >> I do agree. I also wish -- something much easier to do -- they would > >> care for our nerval systems & stop saturating them with non-information > >> (white backgrounds). > > > > Is there any scientific data to back this assumption? > > > > David > > Paper has white background, which worked quite well for it. The problem with a white background on a computer screen is that a computer screen projects light whereas paper merely reflects it. So, while reading black on white works great with paper, it's harder on the eyes with a computer screen. But naturally, the folks doing the computer stuff have typically emulated paper, so most text read via the computer is still black on white. This can help cause eye strain though, which is one of the reason that there are plenty of programmers out there who mess with the color scheme of at least their code editor to make it light text on a dark background. Now, beyond some eye strain in some folks, I'm not aware of there being any real problems with black text on white with a computer screen - certainly nothing about the saturation of light with non-information harming your nervous system (I'm really not sure what Spir means here). But I don't think that there's much question that reading black on white is harder on your eyes on a computer screen than it is on paper. Still, I wouldn't expect computers to do white on black or anything similar at this point. The whole black on white thing is just too ingrained in people. - Jonathan M Davis
Re: "Code Sandwiches"
On 03/11/2011 04:35 PM, Andrei Alexandrescu wrote: On 3/11/11 5:21 AM, David Nadlinger wrote: On 3/11/11 11:30 AM, spir wrote: I do agree. I also wish -- something much easier to do -- they would care for our nerval systems & stop saturating them with non-information (white backgrounds). Is there any scientific data to back this assumption? David Paper has white background, which worked quite well for it. Paper is not a light emitter. Denis -- _ vita es estrany spir.wikidot.com
Re: "Code Sandwiches"
On 3/11/11 5:55 PM, Jonathan M Davis wrote: The problem with a white background on a computer screen is that a computer screen projects light whereas paper merely reflects it. So, while reading black on white works great with paper, it's harder on the eyes with a computer screen. My question from above still remains: Is there any scientific data to back this assumption? David
Re: "Code Sandwiches"
On 3/9/2011 10:18 PM, Nick Sabalausky wrote: They're text. With minor formatting. That alone makes html better. Html is lousy for a lot of things, but formatted text is the one thing it's always been perfectly good at. And frankly I think I'd *rather* go with pretty much any word processing format if the only other option was pdf. I used to use HTML for presentations. Frankly, it was terrible. The text was rendered badly, especially when blown up on a screen. I could never get it to look right. I couldn't email the presentation to anyone without sending a wad of other files along with it. I switched to pdf presentations, and they worked great and looked great. The pdf viewers would render text that looked great blown up. The pdf was all in one file, meaning I could email it to someone and they could look at it directly from their mail program. I would bring backups on a thumb drive so in case my laptop was busted/stolen by the TSA, I could run my presentation on anyone's computer. I do not understand why HTML engines do such an ugly job rendering text, while PDF's on the same machine do a great job. This is true on Windows as well as Ubuntu.
Re: "Code Sandwiches"
Walter Bright Wrote: > On 3/9/2011 10:18 PM, Nick Sabalausky wrote: > > They're text. With minor formatting. That alone makes html better. Html is > > lousy for a lot of things, but formatted text is the one thing it's always > > been perfectly good at. And frankly I think I'd *rather* go with pretty much > > any word processing format if the only other option was pdf. > > I used to use HTML for presentations. Frankly, it was terrible. The text was > rendered badly, especially when blown up on a screen. I could never get it to > look right. I couldn't email the presentation to anyone without sending a wad > of > other files along with it. > > I switched to pdf presentations, and they worked great and looked great. The > pdf > viewers would render text that looked great blown up. The pdf was all in one > file, meaning I could email it to someone and they could look at it directly > from their mail program. I would bring backups on a thumb drive so in case my > laptop was busted/stolen by the TSA, I could run my presentation on anyone's > computer. > > I do not understand why HTML engines do such an ugly job rendering text, > while > PDF's on the same machine do a great job. This is true on Windows as well as > Ubuntu. This can't be true! Walter defending inferior semi-standard formats. PDF doesn't even have as nice transition effects as powerpoint or new jQuery using presentations stored in the cloud services. Your thumb drives break anyway once a year so I'm in favor of a subscription model for the cloud. Stardard HTML + CSS + JavaScript or Flash works for everyone. There's also Silverlight coming soon.
Re: "Code Sandwiches"
Transition effects? Is this the 90s?
Re: "Code Sandwiches"
"lurker" wrote in message news:ile1fe$2i8q$1...@digitalmars.com... > Walter Bright Wrote: > >> On 3/9/2011 10:18 PM, Nick Sabalausky wrote: >> > They're text. With minor formatting. That alone makes html better. Html >> > is >> > lousy for a lot of things, but formatted text is the one thing it's >> > always >> > been perfectly good at. And frankly I think I'd *rather* go with pretty >> > much >> > any word processing format if the only other option was pdf. >> >> I used to use HTML for presentations. Frankly, it was terrible. The text >> was >> rendered badly, especially when blown up on a screen. I could never get >> it to >> look right What specifically was done badly? >> I switched to pdf presentations, and they worked great and looked great. >> The pdf >> viewers would render text that looked great blown up. The pdf was all in >> one >> file, meaning I could email it to someone and they could look at it >> directly >> from their mail program. I would bring backups on a thumb drive so in >> case my >> laptop was busted/stolen by the TSA, I could run my presentation on >> anyone's >> computer. >> Well, PDF's are designed for a page-by-page medium, and presentation slides do fit that bill, unlike documents. > > This can't be true! Walter defending inferior semi-standard formats. PDF > doesn't even have as nice transition effects as powerpoint or new jQuery > using presentations stored in the cloud services. Ugh. Transition effects are cheesy. (Hollywood avoids them for a reason.) > Your thumb drives break anyway once a year so I'm in favor of a > subscription model for the cloud. I've never had a USB drive or an SD card die on me. And I've been using the cheap no-name ones from MicroCenter. Maybe you're just using *really* bad ones or being rough on them? Or spend time near strong em fields? I'm going to try to refrain from saying anything about "the cloud". Don't really feel like another big debate, atm.
Re: "Code Sandwiches"
Nick Sabalausky Wrote: > I've never had a USB drive or an SD card die on me. And I've been using the > cheap no-name ones from MicroCenter. Maybe you're just using *really* bad > ones or being rough on them? Or spend time near strong em fields? You might forget them in the wrong pocket or your dog might bite the usb connector into pieces. I also don't like the unmount feature. You sometimes forget to sync data and boom the whole file system is corrupt.
Re: "Code Sandwiches"
"lurker" wrote in message news:ile4mh$2qoe$1...@digitalmars.com... > Nick Sabalausky Wrote: > >> I've never had a USB drive or an SD card die on me. And I've been using >> the >> cheap no-name ones from MicroCenter. Maybe you're just using *really* bad >> ones or being rough on them? Or spend time near strong em fields? > > You might forget them in the wrong pocket or your dog might bite the usb > connector into pieces. Outside of chinese restaurants, I hate dogs, so that second part isn't a problem for me ;) > I also don't like the unmount feature. You sometimes forget to sync data > and boom the whole file system is corrupt. Yea. I have always thought it seemed strange that "modern" removable media lacks the sensible lock/eject system that CD-ROM drives have had since the 90's.
Re: "Code Sandwiches"
On Friday, March 11, 2011 11:18:59 David Nadlinger wrote: > On 3/11/11 5:55 PM, Jonathan M Davis wrote: > > The problem with a white background on a computer screen is that a > > computer screen projects light whereas paper merely reflects it. So, > > while reading black on white works great with paper, it's harder on the > > eyes with a computer screen. > > My question from above still remains: Is there any scientific data to > back this assumption? I don't know. I haven't gone looking. However, I know that there's lots of anecdotal evidence for it. There's probably experimental evidence as well, but I haven't gone looking for it. Personally, I know that my eyes do much better when I have a dark background and light text on the screen. It's much harder on my eyes to have a white background with black text. None of those problems occur with paper. - Jonathan M Davis
Re: "Code Sandwiches"
On 3/11/2011 1:21 PM, Nick Sabalausky wrote: "lurker" wrote in message news:ile1fe$2i8q$1...@digitalmars.com... Walter Bright Wrote: On 3/9/2011 10:18 PM, Nick Sabalausky wrote: They're text. With minor formatting. That alone makes html better. Html is lousy for a lot of things, but formatted text is the one thing it's always been perfectly good at. And frankly I think I'd *rather* go with pretty much any word processing format if the only other option was pdf. I used to use HTML for presentations. Frankly, it was terrible. The text was rendered badly, especially when blown up on a screen. I could never get it to look right What specifically was done badly? Something as simple as getting the text to be rendered attractively. HTML text looks ragged blown up. HTML fonts simply do not look good. There were other problems such as the presentation machine differing slightly from my dev machine, throwing everything off. The HTML stuff was so bad that I regularly got pretty negative feedback about it. Those problems all vanished when I switched to pdf. No complaints. I'm going to try to refrain from saying anything about "the cloud". Don't really feel like another big debate, atm. As if I'm really going to have my presentation hinge on getting a reliable internet connection. (I've seen some that did, and they always got derailed and spent their allotted time trying to get it to work.) One huge impediment to me doing cloud computing is the random nature of responsiveness of the internet. And, when it is not responding, the software gives you no clue what the problem is: 1. your browser crashed 2. your browser is slowly executing javascript 3. your ethernet cable fell out of its socket again 4. your hub needs to be power cycled 5. another machine on your lan is hogging the bandwidth 6. your router needs to be rebooted 7. your cable modem needs to be rebooted 8. your ISP needs to be rebooted 9. a tree fell on the wires again 10. the internet is just slow today 11. any of the above happened to the web site you're trying to access
Re: "Code Sandwiches"
On 3/11/11 11:17 PM, Jonathan M Davis wrote: On Friday, March 11, 2011 11:18:59 David Nadlinger wrote: My question from above still remains: Is there any scientific data to back this assumption? I don't know. I haven't gone looking. However, I know that there's lots of anecdotal evidence for it. There's probably experimental evidence as well, but I haven't gone looking for it. The reason I'm asking is that while I can understand that you might personally prefer light text on dark backgrounds, I don't think that this can be generalized so easily. I don't know of any research specifically studying eyestrain, but there are results indicating that *black-on-white* text is significantly easier to read, e.g. Hall and Hanna (2004) [1] or Bucher and Baumgartner (2007) [2]. Also, while I don't want to doubt that you know lots of anecdotal evidence favoring light-on-dark text, I think there is probably more for the opposite: Just look at the standard text settings of most widely used OS/DEs out there, or at the color scheme of the most frequented web sites, etc. Light-on-dark color schemes certainly had their advantages on early monitors (flicker, tearing), but with today's sophisticated screens, I personally prefer dark text on light backgrounds. Even with a brightness setting matching the ambient light (many people I know have turned the backlight up way too high), longer blocks of white text on a dark background have the nasty habit of leaving an after-image in my eyes, as demonstrated by this site: http://www.ironicsans.com/owmyeyes/. David [1] http://sigs.aisnet.org/sighci/bit04/BIT_Hall.pdf [2] http://www.psycho.uni-duesseldorf.de/abteilungen/aap/Dokumente/Ergonomics-2007-Text-background-polarity.pdf
Re: "Code Sandwiches"
"David Nadlinger" wrote in message news:ilgjnj$1oui$1...@digitalmars.com... > On 3/11/11 11:17 PM, Jonathan M Davis wrote: >> On Friday, March 11, 2011 11:18:59 David Nadlinger wrote: >>> My question from above still remains: Is there any scientific data to >>> back this assumption? >> >> I don't know. I haven't gone looking. However, I know that there's lots >> of >> anecdotal evidence for it. There's probably experimental evidence as >> well, but I >> haven't gone looking for it. > > The reason I'm asking is that while I can understand that you might > personally prefer light text on dark backgrounds, I don't think that this > can be generalized so easily. > That may be a very fair point. > I don't know of any research specifically studying eyestrain, but there > are results indicating that *black-on-white* text is significantly easier > to read, e.g. Hall and Hanna (2004) [1] or Bucher and Baumgartner (2007) > [2]. > > Also, while I don't want to doubt that you know lots of anecdotal evidence > favoring light-on-dark text, I think there is probably more for the > opposite: Just look at the standard text settings of most widely used > OS/DEs out there, or at the color scheme of the most frequented web sites, > etc. > > Light-on-dark color schemes certainly had their advantages on early > monitors (flicker, tearing), but with today's sophisticated screens, I > personally prefer dark text on light backgrounds. Even with a brightness > setting matching the ambient light (many people I know have turned the > backlight up way too high), longer blocks of white text on a dark > background have the nasty habit of leaving an after-image in my eyes, as > demonstrated by this site: http://www.ironicsans.com/owmyeyes/. > That's a very poor example of light-on-dark: It's all-bold, pure-white on pure-black. Even light-on-dark fans don't do that. The "white" is normally a grey. > > [1] http://sigs.aisnet.org/sighci/bit04/BIT_Hall.pdf > [2] > http://www.psycho.uni-duesseldorf.de/abteilungen/aap/Dokumente/Ergonomics-2007-Text-background-polarity.pdf Neither of those (and from what I noticed when I skimmed through, none of the experiments they cited) appear to take into account whether the subject is more accustomed to positive contrast or negative contrast. Since most people are more accustomed to positive contrast I would expect the findings to be biased in favor of positive contrast. FWIW, I found the white backgrounds of those pdf's to be rather eye-searing. Eventually ended up looking for a "use system color settings" option in my pdf reader.
Re: "Code Sandwiches"
On 03/12/2011 10:16 PM, Nick Sabalausky wrote: Even with a brightness > setting matching the ambient light (many people I know have turned the > backlight up way too high), longer blocks of white text on a dark > background have the nasty habit of leaving an after-image in my eyes, as > demonstrated by this site:http://www.ironicsans.com/owmyeyes/. > That's a very poor example of light-on-dark: It's all-bold, pure-white on pure-black. Even light-on-dark fans don't do that. The "white" is normally a grey. It's very strange. What the text on this page explains, complaining about light text on dark background, is exactly what I experience when reading text with the opposite combination, eg PDFs. His text holds a link that switches colors (thus suddenly displaying black on white): this kills my eyes! I have to zap away at once. I must admit I'm kind of an exceptional case in that my eyes are extra sensitive to light (there are called "pair" eyes in french, I don't know the english term). On the nice side, I can see very well at night, on the other side, excess light hurts me badly very fast. But an ophtalmologist explained me what I experience is just normal reaction, simply over-sensitive, that what hurts me strongly and fast hurts everyone else on the long run (sounds obvious). Another obvious remark (not from me, read on the web) is that what is good for paper is not good for screens; because they are light sources. Reading text on white backgroung is like staring at an intensely luminous sky, without moving your sight: doesn't this hurt you? On this other hand, it seems that pure white text on pure black bg is far too be an optimal combination; text looks hard too read. I guess the reason is that fonts are originally drawn for the opposite combination, and also for paper. Full B/W or W/B contrast seems a bad scheme in both cases. What looks nice and readible instead is choosing ~ 25% lightness bg, 75% lightness fg, with the same hue; one can also adjust saturation to increase or decrease contrast. The opposite (dark on light with 25%/75% saturation) is also pleasant and non-agressive. Why insist on imposing black on white? I guess this has to do with our civilisation demanding clean / white / uniform things. Like hospitals. An esthetic of death. (Sorry for the personal tone, if ever you mind.) Denis -- _ vita es estrany spir.wikidot.com
Re: "Code Sandwiches"
On 3/12/11 11:07 PM, spir wrote: Another obvious remark (not from me, read on the web) is that what is good for paper is not good for screens; because they are light sources. Reading text on white backgroung is like staring at an intensely luminous sky, without moving your sight: doesn't this hurt you? Only if you have turned up the brightness/backlight of your monitor way too high… David
Re: "Code Sandwiches"
"spir" wrote in message news:mailman.2474.1299967680.4748.digitalmar...@puremagic.com... > On 03/12/2011 10:16 PM, Nick Sabalausky wrote: >>> Even with a brightness >>> > setting matching the ambient light (many people I know have turned >>> > the >>> > backlight up way too high), longer blocks of white text on a dark >>> > background have the nasty habit of leaving an after-image in my eyes, >>> > as >>> > demonstrated by this site:http://www.ironicsans.com/owmyeyes/. >>> > >> That's a very poor example of light-on-dark: It's all-bold, pure-white on >> pure-black. Even light-on-dark fans don't do that. The "white" is >> normally a >> grey. > > It's very strange. What the text on this page explains, complaining about > light text on dark background, is exactly what I experience when reading > text with the opposite combination, eg PDFs. > His text holds a link that switches colors (thus suddenly displaying black > on white): this kills my eyes! I have to zap away at once. > Yea, I have a hard time looking at that version, too. And I didn't even see it until after I was away from the page for about an hour and then came back. There are also other reasons that both versions of that page are hard to read: - All bold. - All justified (I honestly do find justified text harder to read than left-algned. And the difference is much more pronounced with narrower text columns, such as that page uses.) - One lng paragraph.
Re: "Code Sandwiches"
On 3/12/11 11:34 PM, Nick Sabalausky wrote: "spir" wrote in message news:mailman.2474.1299967680.4748.digitalmar...@puremagic.com... On 03/12/2011 10:16 PM, Nick Sabalausky wrote: Even with a brightness setting matching the ambient light (many people I know have turned the backlight up way too high), longer blocks of white text on a dark background have the nasty habit of leaving an after-image in my eyes, as demonstrated by this site:http://www.ironicsans.com/owmyeyes/. That's a very poor example of light-on-dark: It's all-bold, pure-white on pure-black. Even light-on-dark fans don't do that. The "white" is normally a grey. It's very strange. What the text on this page explains, complaining about light text on dark background, is exactly what I experience when reading text with the opposite combination, eg PDFs. His text holds a link that switches colors (thus suddenly displaying black on white): this kills my eyes! I have to zap away at once. Yea, I have a hard time looking at that version, too. And I didn't even see it until after I was away from the page for about an hour and then came back. There are also other reasons that both versions of that page are hard to read: - All bold. - All justified (I honestly do find justified text harder to read than left-algned. And the difference is much more pronounced with narrower text columns, such as that page uses.) - One lng paragraph. Oh, really? I guess there is no way this site could be a fabricated example for clearly demonstrating the effect, right?
Re: "Code Sandwiches"
"David Nadlinger" wrote in message news:ilgs4q$27rk$1...@digitalmars.com... > On 3/12/11 11:07 PM, spir wrote: >> Another obvious remark (not from me, read on the web) is that what is >> good for paper is not good for screens; because they are light sources. >> Reading text on white backgroung is like staring at an intensely >> luminous sky, without moving your sight: doesn't this hurt you? > > Only if you have turned up the brightness/backlight of your monitor way > too high. > I have the same effect as him, but my monitor is so dark that when I look at an image or video that has low lighting (such as any typical night-time scene in hollywood movies, or any low-lit room in an FPS) I can barely see anything at all. My monitor is so dark that a large square of 0x252525 is barely distinguishable from a large 0x00 square right next to it. And my contrast isn't too high: Any lower is noticably overly-dark and overly-washed-out. And, of course, pure-white on pure-black doesn't give me any bloom.
Re: "Code Sandwiches"
"David Nadlinger" wrote in message
news:ilgt04$298s$1...@digitalmars.com...
> On 3/12/11 11:34 PM, Nick Sabalausky wrote:
>> "spir" wrote in message
>> news:mailman.2474.1299967680.4748.digitalmar...@puremagic.com...
>>> On 03/12/2011 10:16 PM, Nick Sabalausky wrote:
> Even with a brightness
>> setting matching the ambient light (many people I know have turned
>> the
>> backlight up way too high), longer blocks of white text on a dark
>> background have the nasty habit of leaving an after-image in my
>> eyes,
>> as
>> demonstrated by this site:http://www.ironicsans.com/owmyeyes/.
>>
That's a very poor example of light-on-dark: It's all-bold, pure-white
on
pure-black. Even light-on-dark fans don't do that. The "white" is
normally a
grey.
>>>
>>> It's very strange. What the text on this page explains, complaining
>>> about
>>> light text on dark background, is exactly what I experience when reading
>>> text with the opposite combination, eg PDFs.
>>> His text holds a link that switches colors (thus suddenly displaying
>>> black
>>> on white): this kills my eyes! I have to zap away at once.
>>>
>>
>> Yea, I have a hard time looking at that version, too. And I didn't even
>> see
>> it until after I was away from the page for about an hour and then came
>> back.
>>
>> There are also other reasons that both versions of that page are hard to
>> read:
>>
>> - All bold.
>> - All justified (I honestly do find justified text harder to read than
>> left-algned. And the difference is much more pronounced with narrower
>> text
>> columns, such as that page uses.)
>> - One lng paragraph.
>
> Oh, really? I guess there is no way this site could be a fabricated
> example for clearly demonstrating the effect, right?
>
Doesn't matter, he's still constructed a blatant strawman. Those three
things I mentioned, plus the fact that he's using maximum contrast, all make
text harder to read *regardless* of positive/negative contrast. And
*despite* that, he's still using those tricks in his attempt to "prove"
something completely different (ie, that light-on-dark is hard to
read/look-at and shouldn't be used). It's exactly the same as if I made
chicken noodle soup with rotted rancid chicken, tossed in some dog shit, and
then tried to claim: "See! Chicken makes food taste terrible!" ("But you
used bad ingredients..." "Well excuse me for trying to clearly demonstrate
the effect!")
Even if it weren't a strawman, it's still exaggerated and unrealistic - and
demonstrating that an excess of something is bad does not indicate that
ordinary usage is bad (salt and fat are perfect examples).
Re: "Code Sandwiches"
On 3/13/11 12:14 AM, Nick Sabalausky wrote:
Doesn't matter, he's still constructed a blatant strawman. Those three
things I mentioned, plus the fact that he's using maximum contrast, all make
text harder to read *regardless* of positive/negative contrast. And
*despite* that, he's still using those tricks in his attempt to "prove"
something completely different (ie, that light-on-dark is hard to
read/look-at and shouldn't be used). It's exactly the same as if I made
chicken noodle soup with rotted rancid chicken, tossed in some dog shit, and
then tried to claim: "See! Chicken makes food taste terrible!" ("But you
used bad ingredients..." "Well excuse me for trying to clearly demonstrate
the effect!")
Even if it weren't a strawman, it's still exaggerated and unrealistic - and
demonstrating that an excess of something is bad does not indicate that
ordinary usage is bad (salt and fat are perfect examples).
Calm down, this isn't a religious war or something, at least not for me.
If you want to try to prove everybody else »wrong«, feel free to do so,
but I just picked that example because it neatly illustrates the effect
I experienced when I was experimenting light-on-dark color schemes in my
text editor/IDE…
David
Re: "Code Sandwiches"
On 3/12/11 11:49 PM, Nick Sabalausky wrote: "David Nadlinger" wrote in message news:ilgs4q$27rk$1...@digitalmars.com... On 3/12/11 11:07 PM, spir wrote: Another obvious remark (not from me, read on the web) is that what is good for paper is not good for screens; because they are light sources. Reading text on white backgroung is like staring at an intensely luminous sky, without moving your sight: doesn't this hurt you? Only if you have turned up the brightness/backlight of your monitor way too high. I have the same effect as him, but my monitor is so dark that […] What effect? In the post you quoted, I was referring specifically to the »obvious remark« by Denis, which only holds for unsuitable monitor brightness settings – even if my monitor was capable of delivering a luminous intensity close to an »intensely luminous sky«, I doubt that I would ever run it at that setting (well, maybe if I was on a sandy beach on a bright summer day). David
Re: "Code Sandwiches"
"David Nadlinger" wrote in message news:ilgvk8$2dmt$2...@digitalmars.com... > On 3/12/11 11:49 PM, Nick Sabalausky wrote: >> "David Nadlinger" wrote in message >> news:ilgs4q$27rk$1...@digitalmars.com... >>> On 3/12/11 11:07 PM, spir wrote: Another obvious remark (not from me, read on the web) is that what is good for paper is not good for screens; because they are light sources. Reading text on white backgroung is like staring at an intensely luminous sky, without moving your sight: doesn't this hurt you? >>> >>> Only if you have turned up the brightness/backlight of your monitor way >>> too high. >>> >> >> I have the same effect as him, but my monitor is so dark that [.] > > What effect? In the post you quoted, I was referring specifically to > the »obvious remark« by Denis, which only holds for unsuitable monitor > brightness settings - even if my monitor was capable of delivering a > luminous intensity close to an »intensely luminous sky«, I doubt that I > would ever run it at that setting (well, maybe if I was on a sandy beach > on a bright summer day). > I meant about positive-contrast being hard on my eyes.
Re: "Code Sandwiches"
"David Nadlinger" wrote in message
news:ilgvf0$2dmt$1...@digitalmars.com...
> On 3/13/11 12:14 AM, Nick Sabalausky wrote:
>> Doesn't matter, he's still constructed a blatant strawman. Those three
>> things I mentioned, plus the fact that he's using maximum contrast, all
>> make
>> text harder to read *regardless* of positive/negative contrast. And
>> *despite* that, he's still using those tricks in his attempt to "prove"
>> something completely different (ie, that light-on-dark is hard to
>> read/look-at and shouldn't be used). It's exactly the same as if I made
>> chicken noodle soup with rotted rancid chicken, tossed in some dog shit,
>> and
>> then tried to claim: "See! Chicken makes food taste terrible!" ("But you
>> used bad ingredients..." "Well excuse me for trying to clearly
>> demonstrate
>> the effect!")
>>
>> Even if it weren't a strawman, it's still exaggerated and unrealistic -
>> and
>> demonstrating that an excess of something is bad does not indicate that
>> ordinary usage is bad (salt and fat are perfect examples).
>
> Calm down, this isn't a religious war or something, at least not for me.
> If you want to try to prove everybody else »wrong«, feel free to do so,
> but I just picked that example because it neatly illustrates the effect I
> experienced when I was experimenting light-on-dark color schemes in my
> text editor/IDE.
>
I'm not upset or worked up about it at all (emotional state usually doesn't
come across in text very well anyway, so it's best not to make assumptions
about it). I was just explaining how that page fails to make the point that
it tries to make. I realize you only brought it up to help describe a
certain effect, and naturally that's fine, but I was objecting more to the
page itself rather than the appropriateness of your reference to it.
Re: "Code Sandwiches"
I wish all apps followed a defined standard and allowed us to set all applications to use dark backgrounds at once. On Linux you can't even set the cursor blinking to be the same for all apps. Either it's a GTK/KDE/XF/Whatever-specific setting, or you have to hunt down some configuration file Sometimes it ends up being in xml format, so you have to read the manual on how to configure an app.., and this was for a hex editor. Gz. Someone wrote a freakin manual on how to set cursor blinking for each app they could think off: http://www.jurta.org/en/prog/noblink Ridiculous. And then Windows is a pita. Right! Commence thread derailment. :-P
