02-26-2010, 05:37 PM | #226 | |
Member
Posts: 13
Karma: 10
Join Date: Oct 2009
Device: none
|
Quote:
I said nothing about the rendering engines. |
|
02-26-2010, 06:05 PM | #227 | |
Wizard
Posts: 2,300
Karma: 1121709
Join Date: Feb 2009
Device: Amazon Kindle 1
|
Quote:
Thus I need a screen that can display it properly to do my work, as being an academic I'll always be referring to the old literature when writing papers in the future. |
|
Advert | |
|
02-26-2010, 06:30 PM | #228 | |
Banned
Posts: 2,094
Karma: 2682
Join Date: Aug 2009
Device: N/A
|
Quote:
Nick_ - Not quite. PDF is a display format more akin to RTF and DVI (a TeX output file) than the markup of X(HT)ML or TeX. PDF's are easier to generate from almost any source media (which, of course, also has its own drawbacks). |
|
02-26-2010, 07:00 PM | #229 |
Wizard
Posts: 4,293
Karma: 529619
Join Date: May 2007
Device: iRex iLiad, DR800SG
|
|
02-26-2010, 07:10 PM | #230 |
Banned
Posts: 2,094
Karma: 2682
Join Date: Aug 2009
Device: N/A
|
Well, I for one would typically use "circumvented" there.
|
Advert | |
|
02-26-2010, 07:19 PM | #231 | |
Guru
Posts: 692
Karma: 27532
Join Date: Dec 2007
Device: Ebookwise 1150 / 1200
|
Quote:
For me, the winner of a standards war must involve a) an open standard (fully documented and all features publicly available - pdf is a fail for me in the context of publicly released user-editable forms/documents, though I love it as a print-only medium for design, documents requiring specific layouts etc) b) a way to display that information following consistent and documented standards (i.e., all our current web-browsers display things differently meaning xhtml/css is a fail in this regard, though they generally get 'close enough' in most circumstances. If a border or the padding on a table is supposed to be 3 pixels, it should be 3 pixels. XHTML allows for different rendering choices (CSS markup) based on device (media), when identified. Perhaps a standard that goes beyond the following choices is needed: all Used for all media type devices aural Used for speech and sound synthesizers braille Used for braille tactile feedback devices embossed Used for paged braille printers handheld Used for small or handheld devices print Used for printers projection Used for projected presentations, like slides screen Used for computer screens tty Used for media using a fixed-pitch character grid, like teletypes and terminals tv Used for television-type devices Something that includes, for example information about resolution and screen size as opposed to the generic "handheld" or "screen". This would allow for modified output depending on device used that goes beyond the current standard (maybe HTML5 CSS4?) allow for this, but I'm not sure. I think that without factoring in BOTH screen size and resolution, html/css will struggle in the long run (though it's wonderfully open!). |
|
02-26-2010, 07:22 PM | #232 |
Wizard
Posts: 4,293
Karma: 529619
Join Date: May 2007
Device: iRex iLiad, DR800SG
|
|
02-26-2010, 07:40 PM | #233 | |||||||
Wizard
Posts: 1,213
Karma: 12890
Join Date: Feb 2009
Location: Amherst, Massachusetts, USA
Device: Sony PRS-505
|
Quote:
Quote:
Why are they different? Quote:
In fact, separation of presentation from content is the usual selling point of LaTeX. The idea was that an academic would only need to change one or two lines at the beginning of the document to add the package that loads the style for a given journal in order to format the article for that journal's paper size and fonts, citation and bibliography style, etc. In fact, this is how most math journal articles are published. This separation is set to become even stronger in LaTeX3. Do you really think it matters whether we flag emphasized text like this: This <em>word</em> is emphasized. (HTML) Or like this: This \emph{word} is emphasized. (LaTeX) ? Do you really think it matters whether we signify paragraph breaks with <p>...</p> or LaTeX's way with two linefeeds? (Except perhaps that the latter is slightly easier to read?) Or whether we write <h2>Chapter Name</h2> (HTML) or \chapter{Chapter Name} (LaTeX) to signify where a chapter starts? Again, the differences in the mark-up languages are unimportant. Quote:
Secondly, as for wide fields of view, there is tremendous amount of research to suggest that reading overly long lines of text causes eye strain, which is why magazines and newspapers organize material into columns. This is not going to change on a computer or other device screen, so having a renderer that can handle such things is (And currently, LaTeX's renderer does columns well... I don't know offhand how to do columns in HTML without manually fixing the column breaks, or whether it's even possible.) The renderer for LaTeX can even handle "visually" aligned margins where, e.g., punctuation can extend slightly into the margin to give a more uniform look, to eliminate reading distractions. Quote:
Take a look here (this is my webpage). I have six different sized PDFs made with LaTeX. These are all made with precisely the same LaTeX souce code. Changing font or font-size, etc., is not any harder with LaTeX than it is with HTML. You're confusing the LaTeX source with the PDFs it generates. It's like confusing HTML with a screenshot of someone's web-browser with particular settings. LaTeX is most often used (these days) to output PDF, but don't confuse PDF with LaTeX. LaTeX can be used to output DVI or PS or even HTML instead. Explain how it's possible that LaTeX can be less flexible than HTML when it can be used to generate HTML? Quote:
Quote:
I don't even disagree with the statement that HTML/CSS is the future of mark-up, but that has nothing to do with the future of rendering or the obsolence of typography. It's like this: we already have excellent way to automate rich typography. LaTeX loaded onto our actual readers, whether it's reading ePub source or LaTeX source or whatever, or any other, could be used to reflow on the fly, but do it well. Since that technology already exists, why do we put up with the much worse looking ebook reading experience we currently get instead? |
|||||||
02-26-2010, 07:50 PM | #234 |
The Dank Side of the Moon
Posts: 35,872
Karma: 118716293
Join Date: Sep 2009
Location: Denver, CO
Device: Kindle2; Kindle Fire
|
|
02-26-2010, 08:19 PM | #235 |
Wizard
Posts: 4,293
Karma: 529619
Join Date: May 2007
Device: iRex iLiad, DR800SG
|
|
02-26-2010, 08:27 PM | #236 |
Banned
Posts: 2,094
Karma: 2682
Join Date: Aug 2009
Device: N/A
|
|
02-26-2010, 08:27 PM | #237 | |
Member
Posts: 13
Karma: 10
Join Date: Oct 2009
Device: none
|
Quote:
XHTML, not HTML! HTML and Latex (and Pdf) do not have separation of content and presentation! |
|
02-26-2010, 08:35 PM | #238 |
Member
Posts: 13
Karma: 10
Join Date: Oct 2009
Device: none
|
People with handicaps use special CSS that help them read easier.
There are W3 standards about that: http://www.w3.org/TR/WCAG10/ |
02-26-2010, 08:38 PM | #239 |
Member
Posts: 13
Karma: 10
Join Date: Oct 2009
Device: none
|
Is it?
Show me how you do (text) animations with Latex and I'll show you how you do animations with XHTML+CSS! Last edited by nick_; 02-26-2010 at 08:42 PM. |
02-26-2010, 08:55 PM | #240 | |||
Wizard
Posts: 1,213
Karma: 12890
Join Date: Feb 2009
Location: Amherst, Massachusetts, USA
Device: Sony PRS-505
|
Quote:
Quote:
Quote:
Last edited by frabjous; 02-26-2010 at 09:00 PM. |
|||
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
iPhone Convert epub format to kindle for iPhone format. Is it possible? | thecyberphotog | Apple Devices | 16 | 03-14-2013 02:04 AM |
Win Vista to Win 7 Upgrade messed up Calibre | Amy44 | Calibre | 2 | 06-01-2010 11:12 PM |
Unutterably Silly Who Will Win The Most Gold? | desertgrandma | Lounge | 187 | 03-02-2010 04:24 PM |
If Only I Could Win..... | PeeBus | Sony Reader | 2 | 06-11-2009 10:03 PM |
Master Format for multi-format eBook Generation? | cerement | Workshop | 43 | 04-01-2009 01:00 PM |