CDRom Project News
- Thread starter hunter
- Start date
Not in my opinion. PDF has the wonderful ability to be a very good representation of a document which displays well on print and screen at any scale to the limits of the graphics resolution. HTML doesn't necessarily print well nor does it scale well (particularly with graphics) on screen or on paper.
Also, any MegaTraveller documents would probably be scanned in. To do the documents in HTML would require someone to scan in the documents, do the OCR, and then lay out the graphics again. Getting a page for page representation of a print copy in HTML is difficult at best for anything of non trivial size.
HTML is good for many things, but representing hard copy versions of document on the screen isn't one of them.
Ron
Not in my opinion. PDF has the wonderful ability to be a very good representation of a document which displays well on print and screen at any scale to the limits of the graphics resolution. HTML doesn't necessarily print well nor does it scale well (particularly with graphics) on screen or on paper.
Also, any MegaTraveller documents would probably be scanned in. To do the documents in HTML would require someone to scan in the documents, do the OCR, and then lay out the graphics again. Getting a page for page representation of a print copy in HTML is difficult at best for anything of non trivial size.
HTML is good for many things, but representing hard copy versions of document on the screen isn't one of them.
Ron
Not in my opinion. PDF has the wonderful ability to be a very good representation of a document which displays well on print and screen at any scale to the limits of the graphics resolution. HTML doesn't necessarily print well nor does it scale well (particularly with graphics) on screen or on paper.
Also, any MegaTraveller documents would probably be scanned in. To do the documents in HTML would require someone to scan in the documents, do the OCR, and then lay out the graphics again. Getting a page for page representation of a print copy in HTML is difficult at best for anything of non trivial size.
HTML is good for many things, but representing hard copy versions of document on the screen isn't one of them.
Ron
HTML + CSS should print fine. The ability to put media tags into your docs is pretty handy. HTMLs scaling on the screen is a function of the rendering engine and most of those are pretty good now.
Getting a page by page layout in HTML with CSS isn't that hard, actually. It is time consuming. But then so would be creating a PDF to make one that was worthwhile.
HTML + CSS is *quite* capable of representing hard copy documents with pagination, etc. and CSS support is continously updating in browsers that have actually put out a release in the past year or two (you know which one I'm not thinking of...).
This may be a case of personal preference moreso than capability. I'll concede PDF format is more page-description oriented than baseline HTML. CSS goes some of the way to addressing this and if you want to go to XML with XSL/XSLT/XSL:FO you can do it pretty well from that direction too.
But HTML doesn't require any particular viewer since there are a whole whack of browsers and most word processors handle it, you can view it plaintext in an editor if you want (I'm thinking PDFs don't fare so well there), and the other problem with PDF is once people use it, they have this nasty temptation to flirt with Adobe's abysmal DRM. Which, as you pointed out, isn't cross-platform.
Getting a page by page layout in HTML with CSS isn't that hard, actually. It is time consuming. But then so would be creating a PDF to make one that was worthwhile.
HTML + CSS is *quite* capable of representing hard copy documents with pagination, etc. and CSS support is continously updating in browsers that have actually put out a release in the past year or two (you know which one I'm not thinking of...).
This may be a case of personal preference moreso than capability. I'll concede PDF format is more page-description oriented than baseline HTML. CSS goes some of the way to addressing this and if you want to go to XML with XSL/XSLT/XSL:FO you can do it pretty well from that direction too.
But HTML doesn't require any particular viewer since there are a whole whack of browsers and most word processors handle it, you can view it plaintext in an editor if you want (I'm thinking PDFs don't fare so well there), and the other problem with PDF is once people use it, they have this nasty temptation to flirt with Adobe's abysmal DRM. Which, as you pointed out, isn't cross-platform.
HTML + CSS should print fine. The ability to put media tags into your docs is pretty handy. HTMLs scaling on the screen is a function of the rendering engine and most of those are pretty good now.
Getting a page by page layout in HTML with CSS isn't that hard, actually. It is time consuming. But then so would be creating a PDF to make one that was worthwhile.
HTML + CSS is *quite* capable of representing hard copy documents with pagination, etc. and CSS support is continously updating in browsers that have actually put out a release in the past year or two (you know which one I'm not thinking of...).
This may be a case of personal preference moreso than capability. I'll concede PDF format is more page-description oriented than baseline HTML. CSS goes some of the way to addressing this and if you want to go to XML with XSL/XSLT/XSL:FO you can do it pretty well from that direction too.
But HTML doesn't require any particular viewer since there are a whole whack of browsers and most word processors handle it, you can view it plaintext in an editor if you want (I'm thinking PDFs don't fare so well there), and the other problem with PDF is once people use it, they have this nasty temptation to flirt with Adobe's abysmal DRM. Which, as you pointed out, isn't cross-platform.
Getting a page by page layout in HTML with CSS isn't that hard, actually. It is time consuming. But then so would be creating a PDF to make one that was worthwhile.
HTML + CSS is *quite* capable of representing hard copy documents with pagination, etc. and CSS support is continously updating in browsers that have actually put out a release in the past year or two (you know which one I'm not thinking of...).
This may be a case of personal preference moreso than capability. I'll concede PDF format is more page-description oriented than baseline HTML. CSS goes some of the way to addressing this and if you want to go to XML with XSL/XSLT/XSL:FO you can do it pretty well from that direction too.
But HTML doesn't require any particular viewer since there are a whole whack of browsers and most word processors handle it, you can view it plaintext in an editor if you want (I'm thinking PDFs don't fare so well there), and the other problem with PDF is once people use it, they have this nasty temptation to flirt with Adobe's abysmal DRM. Which, as you pointed out, isn't cross-platform.
HTML + CSS should print fine. The ability to put media tags into your docs is pretty handy. HTMLs scaling on the screen is a function of the rendering engine and most of those are pretty good now.
Getting a page by page layout in HTML with CSS isn't that hard, actually. It is time consuming. But then so would be creating a PDF to make one that was worthwhile.
HTML + CSS is *quite* capable of representing hard copy documents with pagination, etc. and CSS support is continously updating in browsers that have actually put out a release in the past year or two (you know which one I'm not thinking of...).
This may be a case of personal preference moreso than capability. I'll concede PDF format is more page-description oriented than baseline HTML. CSS goes some of the way to addressing this and if you want to go to XML with XSL/XSLT/XSL:FO you can do it pretty well from that direction too.
But HTML doesn't require any particular viewer since there are a whole whack of browsers and most word processors handle it, you can view it plaintext in an editor if you want (I'm thinking PDFs don't fare so well there), and the other problem with PDF is once people use it, they have this nasty temptation to flirt with Adobe's abysmal DRM. Which, as you pointed out, isn't cross-platform.
Getting a page by page layout in HTML with CSS isn't that hard, actually. It is time consuming. But then so would be creating a PDF to make one that was worthwhile.
HTML + CSS is *quite* capable of representing hard copy documents with pagination, etc. and CSS support is continously updating in browsers that have actually put out a release in the past year or two (you know which one I'm not thinking of...).
This may be a case of personal preference moreso than capability. I'll concede PDF format is more page-description oriented than baseline HTML. CSS goes some of the way to addressing this and if you want to go to XML with XSL/XSLT/XSL:FO you can do it pretty well from that direction too.
But HTML doesn't require any particular viewer since there are a whole whack of browsers and most word processors handle it, you can view it plaintext in an editor if you want (I'm thinking PDFs don't fare so well there), and the other problem with PDF is once people use it, they have this nasty temptation to flirt with Adobe's abysmal DRM. Which, as you pointed out, isn't cross-platform.
HTML + CSS is very cross platform, but unlike PDF, is NO GUARANTEE of formatting. CSS is not well implemented across the board; you do not have a certainty of output appearance, unless ALL the content is graphical; text is still HTML, which is not a page description layout. (Go read the HTML and CSS Recs at www.w3c.org)
PDF, however, is a page description language. It describes a layout, specifies point sizes, etc. Assuming you dont' tell acrobat to do weird stuff, it prints nearly identical on every unix, linux, win, and mac released since 1990...
CSS enabled browsers only work on newer machines, and many times subtle differences in system contents will make a CSS page change appearance, sometimes radically (Font substitution issues are the most common there.)
And some of us don't use the "Big Two" for security, OS, and/or sanity reasons. (In my case, because IE for OSX is particularly crashy, and apple has released a much more stable browser: Safari.)
PDF, however, is a page description language. It describes a layout, specifies point sizes, etc. Assuming you dont' tell acrobat to do weird stuff, it prints nearly identical on every unix, linux, win, and mac released since 1990...
CSS enabled browsers only work on newer machines, and many times subtle differences in system contents will make a CSS page change appearance, sometimes radically (Font substitution issues are the most common there.)
And some of us don't use the "Big Two" for security, OS, and/or sanity reasons. (In my case, because IE for OSX is particularly crashy, and apple has released a much more stable browser: Safari.)
HTML + CSS is very cross platform, but unlike PDF, is NO GUARANTEE of formatting. CSS is not well implemented across the board; you do not have a certainty of output appearance, unless ALL the content is graphical; text is still HTML, which is not a page description layout. (Go read the HTML and CSS Recs at www.w3c.org)
PDF, however, is a page description language. It describes a layout, specifies point sizes, etc. Assuming you dont' tell acrobat to do weird stuff, it prints nearly identical on every unix, linux, win, and mac released since 1990...
CSS enabled browsers only work on newer machines, and many times subtle differences in system contents will make a CSS page change appearance, sometimes radically (Font substitution issues are the most common there.)
And some of us don't use the "Big Two" for security, OS, and/or sanity reasons. (In my case, because IE for OSX is particularly crashy, and apple has released a much more stable browser: Safari.)
PDF, however, is a page description language. It describes a layout, specifies point sizes, etc. Assuming you dont' tell acrobat to do weird stuff, it prints nearly identical on every unix, linux, win, and mac released since 1990...
CSS enabled browsers only work on newer machines, and many times subtle differences in system contents will make a CSS page change appearance, sometimes radically (Font substitution issues are the most common there.)
And some of us don't use the "Big Two" for security, OS, and/or sanity reasons. (In my case, because IE for OSX is particularly crashy, and apple has released a much more stable browser: Safari.)
HTML + CSS is very cross platform, but unlike PDF, is NO GUARANTEE of formatting. CSS is not well implemented across the board; you do not have a certainty of output appearance, unless ALL the content is graphical; text is still HTML, which is not a page description layout. (Go read the HTML and CSS Recs at www.w3c.org)
PDF, however, is a page description language. It describes a layout, specifies point sizes, etc. Assuming you dont' tell acrobat to do weird stuff, it prints nearly identical on every unix, linux, win, and mac released since 1990...
CSS enabled browsers only work on newer machines, and many times subtle differences in system contents will make a CSS page change appearance, sometimes radically (Font substitution issues are the most common there.)
And some of us don't use the "Big Two" for security, OS, and/or sanity reasons. (In my case, because IE for OSX is particularly crashy, and apple has released a much more stable browser: Safari.)
PDF, however, is a page description language. It describes a layout, specifies point sizes, etc. Assuming you dont' tell acrobat to do weird stuff, it prints nearly identical on every unix, linux, win, and mac released since 1990...
CSS enabled browsers only work on newer machines, and many times subtle differences in system contents will make a CSS page change appearance, sometimes radically (Font substitution issues are the most common there.)
And some of us don't use the "Big Two" for security, OS, and/or sanity reasons. (In my case, because IE for OSX is particularly crashy, and apple has released a much more stable browser: Safari.)
I was referring specifically to the interface being in some sort of html instead of some sort of a custom Windows-only interface that likely won't look much better and crash anyway.
(my experience with such things) List of files, some basic graphics, lots of linkage, maybe some background or other tidbits though those could be in pdf as well.
As for the books themselves pdf at least. I suppose other versions would be ok but
1) this would require TPTB to take more time on this
2) pdfs are pretty much the standard for book duplication. Just ensure that they are OCRd and searchable and I'd be happy.
As for the books themselves pdf at least. I suppose other versions would be ok but
1) this would require TPTB to take more time on this
2) pdfs are pretty much the standard for book duplication. Just ensure that they are OCRd and searchable and I'd be happy.
I was referring specifically to the interface being in some sort of html instead of some sort of a custom Windows-only interface that likely won't look much better and crash anyway.
(my experience with such things) List of files, some basic graphics, lots of linkage, maybe some background or other tidbits though those could be in pdf as well.
As for the books themselves pdf at least. I suppose other versions would be ok but
1) this would require TPTB to take more time on this
2) pdfs are pretty much the standard for book duplication. Just ensure that they are OCRd and searchable and I'd be happy.
As for the books themselves pdf at least. I suppose other versions would be ok but
1) this would require TPTB to take more time on this
2) pdfs are pretty much the standard for book duplication. Just ensure that they are OCRd and searchable and I'd be happy.
I was referring specifically to the interface being in some sort of html instead of some sort of a custom Windows-only interface that likely won't look much better and crash anyway.
(my experience with such things) List of files, some basic graphics, lots of linkage, maybe some background or other tidbits though those could be in pdf as well.
As for the books themselves pdf at least. I suppose other versions would be ok but
1) this would require TPTB to take more time on this
2) pdfs are pretty much the standard for book duplication. Just ensure that they are OCRd and searchable and I'd be happy.
As for the books themselves pdf at least. I suppose other versions would be ok but
1) this would require TPTB to take more time on this
2) pdfs are pretty much the standard for book duplication. Just ensure that they are OCRd and searchable and I'd be happy.
Fundamentally, the reason I suggested a PDF master interface is so that there is only ONE application involved. This isn't terribly important on desktops, but when I D/L it to a PDA, I don't HAVE HTML readers, but the inter-document links WILL work in AcroReader for Palm.
One file type, cross platform.
One file type, cross platform.
Fundamentally, the reason I suggested a PDF master interface is so that there is only ONE application involved. This isn't terribly important on desktops, but when I D/L it to a PDA, I don't HAVE HTML readers, but the inter-document links WILL work in AcroReader for Palm.
One file type, cross platform.
One file type, cross platform.
Fundamentally, the reason I suggested a PDF master interface is so that there is only ONE application involved. This isn't terribly important on desktops, but when I D/L it to a PDA, I don't HAVE HTML readers, but the inter-document links WILL work in AcroReader for Palm.
One file type, cross platform.
One file type, cross platform.
RobertFisher
SOC-12
I could've sworn I loaded a free HTML reader onto my Palm before. (Well, you had to process the HTML into its own format, but that's no different than Acrobat for Palm.)
Besides, you're a Mac OS X guy, right. You can print to PDF from any app including Safari. (& I've got free tools to let me do the same on Windows & Linux.)
But it looks like the MT disk is going to be PDFs, & that's fine by me. Especially if they're OCRd so that I can pull the text out & put it into HTML or whatever format is best for the device I want to carry it on. (Perhaps my Rocket eBook...)
I'm just going to have to find a spot for it in my game purchasing queue/budget.
RobertFisher
SOC-12
I could've sworn I loaded a free HTML reader onto my Palm before. (Well, you had to process the HTML into its own format, but that's no different than Acrobat for Palm.)
Besides, you're a Mac OS X guy, right. You can print to PDF from any app including Safari. (& I've got free tools to let me do the same on Windows & Linux.)
But it looks like the MT disk is going to be PDFs, & that's fine by me. Especially if they're OCRd so that I can pull the text out & put it into HTML or whatever format is best for the device I want to carry it on. (Perhaps my Rocket eBook...)
I'm just going to have to find a spot for it in my game purchasing queue/budget.
RobertFisher
SOC-12
I could've sworn I loaded a free HTML reader onto my Palm before. (Well, you had to process the HTML into its own format, but that's no different than Acrobat for Palm.)
Besides, you're a Mac OS X guy, right. You can print to PDF from any app including Safari. (& I've got free tools to let me do the same on Windows & Linux.)
But it looks like the MT disk is going to be PDFs, & that's fine by me. Especially if they're OCRd so that I can pull the text out & put it into HTML or whatever format is best for the device I want to carry it on. (Perhaps my Rocket eBook...)
I'm just going to have to find a spot for it in my game purchasing queue/budget.
I'm just saying, if there is an EXE driven interface, it excludes macs and many linux users, and means more bloat on the PDA.
If it includes an HTML based interface, that means at least two programs.
If it includes an autorun launcher with a PDF Menu with extern links, that can be set to run on both Mac and Wintel, and is one command line away for linux, unix, OS2, and several others, and is all within a single running program.
If it includes an HTML based interface, that means at least two programs.
If it includes an autorun launcher with a PDF Menu with extern links, that can be set to run on both Mac and Wintel, and is one command line away for linux, unix, OS2, and several others, and is all within a single running program.
