April 25, 2014
On 4/24/2014 6:54 PM, bearophile wrote:
> Some combinations of PDF readers and PDF files support reflow, so later you can
> also increase the zoom. Another solution is to buy a wider screen, now even wide
> ones are kind of cheap.

Wider ones won't help. You'd need a taller one.

April 25, 2014
On 4/24/2014 9:54 PM, bearophile wrote:
> Walter Bright:
>> I don't get the reason for doing this. Are they trying to save paper
>> or something?
>
> They are often trying to save paper. Some conferences (and sometimes
> even some journals) set a maximum limit of pages for submitted papers.
>

Don't they write them in Latex and then generate the PDF? You'd think it'd be trivial to generate the microscope version to send off to those who expect it, and then generate a proper one for actual reading. This isn't exactly 1970 typewriter-era, after all.

April 25, 2014
On 4/24/2014 10:07 PM, H. S. Teoh via Digitalmars-d wrote:
>
> I don't like wide screens that much, actually. I still prefer 4x3 aspect
> ratio. I kinda agree with Nick that wide screens are more like
> half-height screens. :-P
>

I've even seen companies actually trying to sell ~2:1 abominations. Even movies (which are perfectly fine in 16:9) are painful to watch in that god-awful ratio - even made "Batman Begins" difficult to watch. Luckily nobody seems dumb enough to reward those devices with actual purchases.

April 25, 2014
On Thu, Apr 24, 2014 at 11:46:16PM -0400, Nick Sabalausky via Digitalmars-d wrote:
> On 4/24/2014 9:54 PM, bearophile wrote:
> >Walter Bright:
> >>I don't get the reason for doing this. Are they trying to save paper or something?
> >
> >They are often trying to save paper. Some conferences (and sometimes even some journals) set a maximum limit of pages for submitted papers.
> >
> 
> Don't they write them in Latex and then generate the PDF? You'd think it'd be trivial to generate the microscope version to send off to those who expect it, and then generate a proper one for actual reading. This isn't exactly 1970 typewriter-era, after all.

True. In theory, you could make your LaTeX document flexible enough to produce two very different outputs depending on the occasion.  I have done this before -- the Turing-complete macro system makes this very easy to do. Of course, it also suffers from the downsides of macro systems: it's very easy to screw up and end up with completely garbled output. :P (And, if not done properly, can lead to your document becoming a write-only mess that even you don't remember how it works -- LaTeX is very much like a programming language.) Which probably explains why most people don't do it. Hmph.

OTOH, I believe journals nowadays actually give you a LaTeX template that you're supposed to follow, and they greatly frown upon submissions that don't conform to that template. So people are less likely to fiddle with stuff that they normally would otherwise.


T

-- 
The trouble with TCP jokes is that it's like hearing the same joke over and over.
April 25, 2014
On 4/25/2014 12:00 AM, H. S. Teoh via Digitalmars-d wrote:
>
> OTOH, I believe journals nowadays actually give you a LaTeX template
> that you're supposed to follow, and they greatly frown upon submissions
> that don't conform to that template. So people are less likely to fiddle
> with stuff that they normally would otherwise.
>

I would think basic computing features like text editing, copy/paste, and filenames would make trivially short work of conforming to various templates upon submission, even for the less technically-inclined.

April 25, 2014
On Fri, Apr 25, 2014 at 12:24:47AM -0400, Nick Sabalausky via Digitalmars-d wrote:
> On 4/25/2014 12:00 AM, H. S. Teoh via Digitalmars-d wrote:
> >
> >OTOH, I believe journals nowadays actually give you a LaTeX template that you're supposed to follow, and they greatly frown upon submissions that don't conform to that template. So people are less likely to fiddle with stuff that they normally would otherwise.
> >
> 
> I would think basic computing features like text editing, copy/paste, and filenames would make trivially short work of conforming to various templates upon submission, even for the less technically-inclined.

True, it's quite easy in LaTeX to split your document into multiple files. One easy way to conform to different templates would be something like:

publisher_template.tex:

	\documentclass{...}
	...	% whatever the publisher predefined
	\input{my_macros.tex}
	\begin{document}
	\input{content.tex}
	\end{document}

readable_template.tex:

	\documentclass{...}
	...	% sane formatting settings here
	\input{my_macros.tex}
	\begin{document}
	\input{content.tex}
	\end{document}

my_macros.tex:

	...	% any additional stuff you want in the preamble,
		% like \newcommand's, and so on.

content.tex:

	...	% put actual article body here

Then running `latex publisher_template.tex` will produce the document to be submitted, `latex readable_template.tex` will produce a more readable version.

I'm not sure if your average journal author is savvy enough to set this up, though. I have the sinking suspicion that probably most of them know just the bare minimum to make LaTeX produce some output, and don't really care about doing things in a more sophisticated way.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before which you can't deliver after.
April 25, 2014
On 4/25/2014 1:06 AM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Apr 25, 2014 at 12:24:47AM -0400, Nick Sabalausky via Digitalmars-d wrote:
>>
>> I would think basic computing features like text editing, copy/paste,
>> and filenames would make trivially short work of conforming to various
>> templates upon submission, even for the less technically-inclined.
>
> True, it's quite easy in LaTeX to split your document into multiple
> files. One easy way to conform to different templates would be something
> like:
>
[...]
>
> I'm not sure if your average journal author is savvy enough to set this
> up, though. I have the sinking suspicion that probably most of them know
> just the bare minimum to make LaTeX produce some output, and don't
> really care about doing things in a more sophisticated way.
>

Actually, I just meant:

- Edit "my_document.tex"
- Publisher requests special version
- Make needed changes, save as "my_document_publisherX.tex"

- Maybe update "my_document.tex" later on
- Same publisher requests the update
- Either copy/paste all non-template content into "my_document_publisherX.tex" or just make the same publisher-specific changes again.
- Or make the changes to "my_document_publisherX.tex" first and then update "my_document.tex".

Obviously not quite as quick and reliable as what a programmer might do, but still pretty damn trivial, and well within the abilities of any author. In fact, it's pretty much what nearly any "average Joe with MS Word" would do without even being told. And they manage to get by fine (much to my puzzlement, sometimes ;) ).

April 25, 2014
On Thursday, 24 April 2014 at 21:48:46 UTC, Nick Sabalausky wrote:
> Markdown:
>
> *italic*
> **bold**
> **_bold and italic_**

That looks like semantic markup. Visual markup would be
/italic/
*bold*
_underlined_

>> I'm thinking more about some standardization of web skins, then people
>> will choose their web skin of choice just like on desktop system, and
>> sites will use that chosen skin to present content and layout.
>
> Unfortunately that'll never happen: It's already hard enough to get *application* developers not to invent their own idiotic user-disrespecting skin (with poorly homespun controls).

It wouldn't prevent using custom styles, it would enable use of user preferences without rolling custom setting manager, what Alexandar is going to do.
April 25, 2014
Different strokes for different folks.
https://github.com/rejectedsoftware/ddox/pull/49
April 25, 2014
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu wrote:
> So I'd dlang.org to foster a behavior depending on the available real estate, as follows:
>
> * Cap cpl at e.g. 110 on very large screens.
>
> * As the available width decreases, reduce cpl up to 60.
>
> * If cpl with sidebar falls below 60, remove the sidebar and obtain e.g. 80 cpl.
>
> * As the available width reduces further, allow reduction down to e.g. 35 cpl, and then require horizontal scrolling.

If the sidebar is not critical, then maybe get rid of it, why bother? If you get 100 cpl on sites without sidebar, then on sites with half page width dedicated for empty space, they would get content at 50 cpl - still in range.

I'm not against 100 cpl, I'm against page width and 1300px, that are much less meaningful values. In fact, that WCAG page displays for me at full page width and 100 cpl, and it has small stylesheet. Why not let user choose? All that complication also results in overblown stylesheets, which are unmanageable without a CSS preprocessor (yikes, just what they have there?). Why solve problem you created yourself?