
holden said:
It seems like you're trying to pick a fight
nope. just sharing information. got any?
The article you post is irrelevant to current XML-based plans for PG.
well, i guess that's a matter of opinion. i think it is relevant, in the sense that it talks about a bunch of much-hyped "solutions" which have not materialized, and now might _never_ come to fruition, including some that are counted on here.
The whole point of the article is that direct delivery of XML to users with stylesheets has not yet happened.
that's one of those "solutions", yes, but just one...
However, from what I've heard about current PG uses of XML, they tend towards using XML as a master format for storage
well yes, and as simon points out, that is a "fallback" position from the one that was originally staked, which was the serving of x.m.l. files. but even this fallback rings hollow here, since the position that x.m.l. is needed for _conversion_to_multiple_formats_ was always a tenuous one, in the sense that many entities out there are already doing mass conversion of p.g. e-texts, even though they aren't in x.m.l. format. further, the x.s.l.t. methodology that has always been the crucial linchpin in the "strategy" of x.m.l. advocates here is one of the ones that simon relegates to the past-tense. i find that interesting. and surely the examples of it that we have seen so far have shown it is badly lacking. add to the equation now that i'm showing, with real example-books, that z.m.l. can convert to multiple formats quite easily, on the user's desktop, via button-clicks, and the question becomes hard to avoid: what's the reason to apply heavy markup? don't get me wrong, i'm sure the hypesters will be able to invent one, they are creative that way, it's just that i think history should warn us to take these with a grain of salt...
On a slight side note, I don't see the point of your aggressive posts
first, my posts are not "aggressive". but if you _choose_ to interpret them that way, then i don't see _your_ point. wouldn't it be better just to skip them? why even bother reading them, holden? (let alone replying to them?) i mean, seriously, i could just as easily interpret _your_ posts as ad hominem, since you've said straight out that i am "trying to pick a fight" with "aggressive posts". but going down that road wouldn't be too productive, so i consciously choose not to; instead i have responded to your post with rebuttals that are on-topic and on-point, without diverting to attack your character. if you want a mud-fight or a flame-war, well i've shown i can do those things too; but why not friendly conversation instead? and don't get me wrong, i don't mean to be disingenuous here, because i fully understand that it's not pleasant to be on the losing side of a "you were wrong" comment. but that's the risk you take when you take a stand and you're wrong. but when someone is wrong, and you say they are wrong, that doesn't mean it's an "aggressive" post.
Everybody here should be (is?) aiming towards the furthering of PG's goals.
well yes, i believe that we all agree on that. the next issue is, "how do we obtain that?" on _that_ question, there is disagreement, which has been longstanding, and ugly too. and as much as some people might like to sweep this disagreement under the carpet, and have people forget what they said since things aren't looking too swell for their side, the disagreement still runs deep, and wide... meanwhile, little progress is being made on "the goals of p.g." that we all agree on... how long does t.e.i./x.m.l./whatever remain on the table as "the official plan" before it's required to show some action and results? how are "the goals of p.g." being served? those are questions i think you all should be asking yourselves. as for me, i'll just keep on plugging away with my little experiments, and maybe someday you'll realize that z.m.l. is best.
If whatever format you choose happens to preferred in the long run, that's not a reason for gloating.
well, i certainly will not be "gloating", because i don't see much point in that. however, it _is_ important to keep in mind whose predictions were wrong, and right, and whose credibility was badly shredded, for future reference... you know, fool me once, your fault, but fool me twice, my fault, right? so surely you can't mind if we evaluate those matters quite closely, can you? besides, in retrospect, my methodologies will be so _obvious_ that no one will even consider their "invention" to be _special_; that it was "controversial" will be laughable. luckily, i'll be able to point to lots and lots of messages that people posted to _this_ listserve as solid evidence that some people didn't get it. (which is why i spent so much time discussing it! y'all would have been a lot smarter to _fold_ your losing hand much earlier in this poker-game than you did, instead of constantly raising your bets...)
The other people on this list are merely trying to help PG as much as we all hope you are.
and i give them full credit on the variable of "trying". that doesn't mean i'm gonna start paying attention to what they say they see in their crystal ball though, because we've come to learn that it's badly cracked... -bowerbird

Bowerbird, I hope you don't mind if I snip your long post. I was unable to find specific sections which would make for a suitable reply so I reply here to your post as a whole. The flaw in your argument, I find, is your suggestion that since PG's XML teams have so far failed to produce any output, XML must be a bad strategy for PG. Your ZML-based strategy has brought forth results and so is better. What is XML? XML is merely a method for devising markup languages. No more, no less. If one project uses XML and, coincidentally, happens to be slow, while another does not and happens to be faster, that does not mean we can attribute such a speed difference to the different languages used, particularly when other factors differ between the two projects. Why has your ZML-based project brought forth results so quickly while others have not? Simply because you are doing a different task to them. Your project is essentially taking standard PG texts and automatically formatting them. From what I've read of the XML team's efforts, they are going back to the original books to ensure they get the formatting from the original books. There is, of course, a trade-off. Going back to the original books to get missing formatting information is extremely time consuming but guarantees accurate results. Your approach does not guarantee accurate results, but settles for well formatted results in most cases, the advantage of which is that it is fast. Blaming a slow start on XML is to miss the point. The XML team could just as well use automatic transformations to convert from PG texts to their XML format, if they chose to. However, their opinion (they are correct) is that such automatic translations as you are using can not capture the full complexity of each book and will not work on every book. Moreover, choosing/defining a suitable format which is capable of retaining every formatting nuance of any given text is not an enviable task. So, please take this as my plea for calm. You and the XML team are working towards different goals. This is not a zero-sum game. If either team produces a great product, it does not come at the expense of the other team. If anything, why not just stop trying to disparage the other team and just get on with producing texts in the best way that you know? Regards, Holden

Bowerbird wrote:
further, the x.s.l.t. methodology that has always been the crucial linchpin in the "strategy" of x.m.l. advocates here is one of the ones that simon relegates to the past-tense. i find that interesting.
Do you think Simon would agree with your assessment of what he is saying? I think you are putting words into his mouth that he did not say or mean. XSLT is being *massively* used in quite a few XML applications, and successfully so. No doubt XSLT has its share of problems as all human-made systems have, but such problems have not stopped it from being used in real-world systems. XSLT is not a theoretical spec -- it is definitely not "vapour." DocBook is one notable success story. O'Reilly uses DocBook in much of its publishing workflow (it was interesting to hear Tim O'Reilly speak at Reading 2.0 -- he's a super-pragmatic person -- they use DocBook and XSLT/XSL-FO because it *makes sense to*.) Rosetta Solutions and other document conversion houses are moving fast to mastering in XML (Rosetta Solutions is using DocBook) and using XSLT (and the related XSL-FO) for outputting in various formats. It's been eye-opening to talk with the several conversion houses (as we have been doing for both OpenReader and LibraryCity.) I also recall seeing a couple online book projects in academia which master in TEI and use XSLT to generate XHTML and other formats. Do a check on Google of "TEI XSLT". 168,000 pages came up. Have fun. If PG/DP has failed so far to move to TEI-based (or other XML vocabulary) mastering, it has little to do with XML, XSLT, etc. It's simply the limited time of the volunteers. I notice that things in PG-Land tend to move slow anyway in most areas, particularly when it comes to change. Look at the problems you've had in getting text errors corrected! (Although maybe that's due to not submitting error reports to the right place.) DP is where most of the action is taking place these days, but even there, DP's long-planned move to a next-gen system (which includes a uniform XML-based mastering) appears to have been put on hold as well (or they're doing it in smaller increments.) They're too busy producing texts. It is the tyranny found in every limited-funded, volunteer organization (and even well-funded orgs): change tends to take a long time unless some bright light steps forward to make something happen. You will no doubt argue, and there is merit in your argument, that your ZML system (which is essentially regularized plain text) is the answer to all PG's and DP's woes, but then you have to *show* that for all the things they'd like to do with their texts in the long-term future, ZML has sufficient structural resolution. But your approach so far to convince others reminds me a lot of the famous advertising slogan of "Ralph's Pretty Good Grocery" (in Garrison Keilor's mythical small-town of Lake Wobegon): "If you can't find it at Ralph's, you can probably get along without it." What's needed on both sides of the debate is a clear cut requirements list of exactly what the "master" format is to accomplish/fulfill. Then this will determine whether the simpler regularized text approach is sufficient, or if an XML-based approach is called for. From my study the last few years in related systems, the XML-based approach is worth the extra work to get there, provided the XML vocabulary is properly chosen and consistently applied. So, your saying that "trust me, ZML is sufficient", is itself an insufficient statement. It's like George Bush saying "trust me, the invasion of Iraq is justified." You even come across like George Bush who "knows" what's good for us but doesn't bother to explain why. Just "trust me, I know what's good for you." Of course, as just noted, there's no agreed to requirements list on which to base any important decision upon, so this debate is sort of being conducted in the dark. Nevertheless, several of the main players in DP and PG have a pretty good intuitive feeling that regularized text is not sufficient. Since XML, properly done, will always surpass ZML in document structure resolution, then the conservative position is XML (better to have more machine-readable document structure than less -- one can always later scale back on the markup if found unnecessary. But if there's a million texts with insufficient structural resolution, then that's a BIG problem.) Also, developing a killer "viewer-app" system for ZML is not sufficient to prove the merit of ZML, either, since visual presentation is simply one use of digital texts. There's other uses such as non-visual presentation, inter-publication linking, annotation, searching/data-mining, machine translation, etc. There's no doubt uses not yet recognized which may require more, not less, document structural identification. Each use adds its own set of requirements. Jon Noring

Bowerbird@aol.com wrote:
add to the equation now that i'm showing, with real example-books, that z.m.l. can convert to multiple formats quite easily, on the user's desktop, via button-clicks,
You forgot to say that the "user's desktop" has to be the computer of your alleged girlfriend, a 1991 Mac running System 7.5. Because on everybody else's desktop it just prints the splash screen and crashes.
how long does t.e.i./x.m.l./whatever remain on the table as "the official plan" before it's required to show some action and results?
There is no official plan. If you can contribute a working technology and convince the people at DP to adopt it, you win. If not, you lose. That's that. But wait! All you did in the last three years was to steal the time and to insult everybody who was trying to do some real work. You'll have a hard time getting people to adopt your gadgets because everybody hates you. And that's a dose of reality for you. What about starting a book distribution site yourself? Servers are cheap. A genius like you will convert the PG library into all kinds of formats in no time at all. Go ahead insted of wasting your precious time with blockheads like us! -- Marcello Perathoner webmaster@gutenberg.org

Now I'm not going to get in the middle of this on going feud, but what readers do we have for each format? The TEI formats are listed there but what do you use to read them so you do not see all the markup encoding. Firefox shows the markup when you open the file. Notepad shows the markup (to be expected). MS Word just crashes upon opening because it says that there are problems with the contents. Going to the gutenberg help page and looking under formats listed there is no information on it (this should have been the first thing done before placing a new format on the site). I understand that behind the scenes there are tools to get these things handled, but why put them on the public site if the tools are not available and a description is not available on how to use them. -----Original Message----- From: gutvol-d-bounces@lists.pglaf.org [mailto:gutvol-d-bounces@lists.pglaf.org] On Behalf Of Marcello Perathoner Sent: Wednesday, March 29, 2006 10:56 AM To: Project Gutenberg Volunteer Discussion Cc: Bowerbird@aol.com Subject: Re: [gutvol-d] another dose of reality Bowerbird@aol.com wrote:
add to the equation now that i'm showing, with real example-books, that z.m.l. can convert to multiple formats quite easily, on the user's desktop, via button-clicks,
You forgot to say that the "user's desktop" has to be the computer of your alleged girlfriend, a 1991 Mac running System 7.5. Because on everybody else's desktop it just prints the splash screen and crashes.
how long does t.e.i./x.m.l./whatever remain on the table as "the official plan" before it's required to show some action and results?
There is no official plan. If you can contribute a working technology and convince the people at DP to adopt it, you win. If not, you lose. That's that. But wait! All you did in the last three years was to steal the time and to insult everybody who was trying to do some real work. You'll have a hard time getting people to adopt your gadgets because everybody hates you. And that's a dose of reality for you. What about starting a book distribution site yourself? Servers are cheap. A genius like you will convert the PG library into all kinds of formats in no time at all. Go ahead insted of wasting your precious time with blockheads like us! -- Marcello Perathoner webmaster@gutenberg.org _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/listinfo.cgi/gutvol-d

Brent Gueth wrote:
Going to the gutenberg help page and looking under formats listed there is no information on it (this should have been the first thing done before placing a new format on the site).
Most of the formats are not described on the help page. Reason: I don't have the time to do it. If you want to help, here is a list of all formats offered on PG. Provide a suitable description (short and concise) of any and I'll post it on the site. gutenberg=> SELECT * from filetypes order by pk; pk | filetype | sortorder | mediatype ------------+------------------------------+-----------+------------------------ ? | Unspecified | 100 | avi | MS Video | 10 | css | CSS Stylesheet | 10 | doc | MS Word Document | 10 | dvi | TeX Device Independent | 10 | eps | Encapsulated PostScript | 10 | application/postscript gif | GIF Picture | 10 | image/gif html | HTML | 5 | text/html index | Index | 3 | iso | ISO CD/DVD Image | 7 | jpg | JPEG Picture | 10 | image/jpeg license | License | 2 | lit | MS Lit for PocketPC | 10 | ly | LilyPond | 10 | md5 | MD5 Checksum | 8 | mid | MIDI | 10 | mp3 | MP3 Audio | 20 | audio/mpeg mpg | MPEG Video | 10 | video/mpeg mus | Finale | 10 | nfo | Proprietary `Folio' format | 50 | pageimages | Raw Page Images | 50 | pdb | Palm Database | 10 | application/vnd.palm pdf | Adobe PDF | 10 | application/pdf png | PNG Picture | 10 | image/png prc | Palm Database | 10 | application/vnd.palm ps | PostScript | 10 | application/postscript ps2 | PostScript Level 2 | 10 | application/postscript qt | Quicktime Video | 10 | video/quicktime readme | Readme | 1 | rtf | MS Rich Text Format | 10 | text/rtf sib | Sibelius | 10 | svg | SVG | 10 | tei | TEI Text Encoding Initiative | 50 | tex | TeX | 10 | tiff | TIFF Picture | 10 | image/tiff tr | Tome Raider | 10 | txt | Plain text | 7 | text/plain wav | MS Wave Audio | 10 | xml | XML | 50 | text/xml xsl | XSLT Stylesheet | 10 | (40 rows) -- Marcello Perathoner webmaster@gutenberg.org

Marcello: How about linking to wikipedia for those we don't have descriptions for? If that's something we're interested in, I'd even be willing to take a stab at creating new Wikipedia entries for those that don't exist in either location. Also, have we thought about making a PG wiki? It might take some of this load off of you, even if we do it as a "staged to the wiki, rolled out to 'production' on a given cycle after all changes in the current cycle have been examined by one of the following trusted people..." to prevent unsavory types from pollution the production site. I'd be more than willing to help setup, maintain, and cross-populate such, if it's something PG is interested in. Here are some wikipedia links for you to use if you so choose. If you want me to make the additional entries, just let me know. avi: http://en.wikipedia.org/wiki/.avi css: http://en.wikipedia.org/wiki/Cascading_Style_Sheets dvi: http://en.wikipedia.org/wiki/DVI_file_format eps: http://en.wikipedia.org/wiki/Encapsulated_PostScript gif: http://en.wikipedia.org/wiki/GIF html: http://en.wikipedia.org/wiki/HTML iso: http://en.wikipedia.org/wiki/ISO_image lit: http://en.wikipedia.org/wiki/Microsoft_Reader ly: http://en.wikipedia.org/wiki/GNU_LilyPond md5: http://en.wikipedia.org/wiki/MD5 mp3: http://en.wikipedia.org/wiki/MP3 mus: http://en.wikipedia.org/wiki/Finale_notation_program pdb: http://en.wikipedia.org/wiki/Palm_OS pdf: http://en.wikipedia.org/wiki/Portable_Document_Format prc: http://en.wikipedia.org/wiki/Palm_OS ps: http://en.wikipedia.org/wiki/PostScript qt: http://en.wikipedia.org/wiki/QuickTime rtf: http://en.wikipedia.org/wiki/RTF sib: http://en.wikipedia.org/wiki/Sibelius_notation_program svg: http://en.wikipedia.org/wiki/SVG tei: http://en.wikipedia.org/wiki/Text_Encoding_Initiative tex: http://en.wikipedia.org/wiki/TeX tiff: http://en.wikipedia.org/wiki/TIFF tr: http://en.wikipedia.org/wiki/TomeRaider xml: http://en.wikipedia.org/wiki/XML xsl: http://en.wikipedia.org/wiki/XSL Also, you may or may not want to apply any of the following to the database. These are brought over from the /etc/mime.types on my debian box, so apply salt to taste. [See, I can make food analogies too! ;)] update filetypes set mediatype = 'video/x-msvideo' where pk = 'avi'; update filetypes set mediatype = 'text/css' where pk = 'css'; update filetypes set mediatype = 'application/msword' where pk = 'doc'; update filetypes set mediatype = 'application/x-dvi' where pk = 'dvi'; update filetypes set mediatype = 'application/x-iso9660-image' where pk = 'iso'; update filetypes set mediatype = 'audio/midi' where pk = 'mid'; update filetypes set mediatype = 'text/plain' where pk = 'readme'; update filetypes set mediatype = 'image/svg+xml' where pk = 'svg'; update filetypes set mediatype = 'audio/x-wav' where pk = 'wav'; update filetypes set mediatype = 'application/xml' where pk = 'xsl';

joey wrote:
How about linking to wikipedia for those we don't have descriptions for? If that's something we're interested in, I'd even be willing to take a stab at creating new Wikipedia entries for those that don't exist in either location.
What we need is a short description like those you find here: http://www.gutenberg.org/help/bibrec#format The average Wikipedia entry is too complex for people who just want to know which format to download.
Also, have we thought about making a PG wiki?
There already is a wiki for the newsletter editors ... not used very often. -- Marcello Perathoner webmaster@gutenberg.org

Marcello wrote:
joey wrote:
How about linking to wikipedia for those we don't have descriptions for? If that's something we're interested in, I'd even be willing to take a stab at creating new Wikipedia entries for those that don't exist in either location.
What we need is a short description like those you find here:
http://www.gutenberg.org/help/bibrec#format
The average Wikipedia entry is too complex for people who just want to know which format to download.
Well, whoever writes the short descriptions can link to Wikipedia articles describing the media types in more detail, and for those where there's no Wikipedia description, to write them. But I agree with Marcello the first step is to write the short descriptions. Jon

On Wed, Mar 29, 2006 at 01:48:20PM -0700, Jon Noring wrote:
Marcello wrote:
joey wrote:
How about linking to wikipedia for those we don't have descriptions for? If that's something we're interested in, I'd even be willing to take a stab at creating new Wikipedia entries for those that don't exist in either location.
What we need is a short description like those you find here:
http://www.gutenberg.org/help/bibrec#format
The average Wikipedia entry is too complex for people who just want to know which format to download.
Well, whoever writes the short descriptions can link to Wikipedia articles describing the media types in more detail, and for those where there's no Wikipedia description, to write them.
But I agree with Marcello the first step is to write the short descriptions.
Jon
I sent a second attempt at "short descriptions", but as far as I can tell, no one has commented on it. I'm assuming that silence means it's unacceptable, so unless someone has specific feedback on how I can improve it, I'll drop the subject.

joey wrote:
I sent a second attempt at "short descriptions", but as far as I can tell, no one has commented on it. I'm assuming that silence means it's unacceptable, so unless someone has specific feedback on how I can improve it, I'll drop the subject.
Its already online. If you want to edit it, download the source code of the help page, edit it and mail it to me. Comments: Never use a link text of "here". Always try to make the link a meaningful text. Focus less on technical details, but try to explain why a user might want to get this format (or not). -- Marcello Perathoner webmaster@gutenberg.org

On Wed, Mar 29, 2006 at 10:39:41PM +0200, Marcello Perathoner wrote:
joey wrote:
How about linking to wikipedia for those we don't have descriptions for? If that's something we're interested in, I'd even be willing to take a stab at creating new Wikipedia entries for those that don't exist in either location.
What we need is a short description like those you find here:
http://www.gutenberg.org/help/bibrec#format
The average Wikipedia entry is too complex for people who just want to know which format to download.
I can do that. I hadn't ever been to this page, so I didn't know what the expectation was.
Also, have we thought about making a PG wiki?
There already is a wiki for the newsletter editors ... not used very often.
That's a "not interested"? As I've previously mentioned, I'd be glad to help maintain stuff, but it's hard when so much of it exists only in your head. Or is there some documentation or a mailing list I'm not aware of? For my part, I don't use the newsletter editor wiki because I'm not a newsletter editor. :)

So, before I get *too* far down this path, here's what I've come up with so far. Is this usable to you? AVI: AVI files can contain both audio and video. They can generally be played with media players such as Windows Media Player, WinAmp, or Mplayer. See <a href="http://en.wikipedia.org/wiki/.avi">here</a> for more information. CSS: CSS (Cascading Style Sheets) are generally used to make HTML pages look nice, and are not intended for direct viewing. Your web browser will find these files as referenced by the HTML files that use them. See <a href="http://en.wikipedia.org/wiki/Cascading_Style_Sheets">here</a> for more information. DVI: The output format of a typesetting system called TeX. Generally more common on Unix-like platforms. Can be viewed using xdvi or Evince. See <a href="http://en.wikipedia.org/wiki/DVI_file_format">here</a> for more information. EPS: Short for "Encapsulated PostScript", it can generally be viewed with any PostScript viewer. A free PostScript viewer is available at <a href="http://www.cs.wisc.edu/~ghost/doc/AFPL/index.htm. See <a href="http://en.wikipedia.org/wiki/Encapsulated_PostScript">here</a> for more information. GIF: An image format generally viewable by any web browser. See <a href="http://en.wikipedia.org/wiki/GIF">here</a> for more information. ISO: A logical copy of a CD-ROM or other optical media. Most CD/DVD authoring utilities can deal with ISO images. A free tool for mounting these images on a Windows machine as though they were inserted into a CD-ROM drive is available <a href="http://www.daemon-tools.cc/dtcc/download.php">here</a>. A tool for burning ISOs to a physical CD-R or CD-RW on Windows is available <a href="http://isorecorder.alexfeinman.com/isorecorder.htm">here</a>.

joey <joey@joeysmith.com> writes:
So, before I get *too* far down this path, here's what I've come up with so far. Is this usable to you?
I think it's a pretty good start. May i suggest you to have a look at this: http://www.openformats.org/ Maybe it's often too didactic/normative for PG's purpose, but i think you can grab some useful content. Some excerpts: * Plain text: http://www.openformats.org/en60 Plain text (ASCII) Whenever possible, just avoid using formatted text: using plain text (either ascii or .txt format) guarantees complete access for everyone, regardless of their software, their operating system or the computer they are using. In your emails, if what is important to you is the content and not the formatting, send the text directly in the body of your message instead of sending it as an attachment. Plain text can carry no virus, it is extremely light and can be easily used to create tables (with tabs or commas) which any software is able to read. * HTML: http://www.openformats.org/en61 Hyper Text Markup Language (HTML) HTML format is the standard language for the web, and it was defined by an standardizing international organization (the W3_Consortium). HTML is a flexible universal format, rich and compact. Native HTML (with no javascript) can carry no virus and can be read on any platform. Note: The HTML code produced by Word is semi-proprietary, and it is prone to include information which cannot be displayed on all platforms. * TeX, LaTeX, DVI: http://www.openformats.org/en62 TeX, LaTeX and Device Independent Format (DVI) TeX is both a language to typeset documents and a programming language. Originally written to typeset mathematical documents in a professional manner, it is now used in many other areas. LaTeX is also a typsetting and programming language. It's actually a simplified version of TeX which enables top level instruction manipulation, just as HTML is a simplified version of SGML. DVI. A TeX or LaTeX source file must be compiled. The result of this compilation is in DVI format, readable on any platform. Most of the time, the result of the compilation will, in turn, be converted to PDF or PS. * OpenDocument: http://www.openformats.org/en62x1 OpenDocument is: a. An open, XML-based file format. b. An open standard, supported by the OASIS and ISO standards groups. c. The default file format for OpenOffice.org 2.0 and KOffice 1.4. d. A top prospect for an official format for the European Commission. e. Our best chance to fight vendor lock-in associated with proprietary formats. * RTF: http://www.openformats.org/en63 Rich Text Format (RTF) RTF format was introduced by Microsoft to create a standard format for text formatting. It offers the same format variety than DOC, all the while being (at least in its native version) a format with public specifications. Most word-processing programs are capable or reading and writing this format, but because certain programs tend to use proprietary extensions of this format, its compatibility remains uncertain. * PS: http://www.openformats.org/en64 PostScript (PS) The PostScript format is a language describing a page, developped by Adobe in 1985, created for printing and widely used in typography. One of its advantages is that it is universal (it is independent from the format of the original file) and it cannot carry viruses. Contrary to PDF format, PostScript does not allow to copy text viewed on a screen to paste it in another application. It can be generated with compatible printers (option: 'print in file') and with the GhostScript program. * PDF: http://www.openformats.org/en65 Portable Document Format (PDF) PDF format (Portable Document Format), developed by Adobe, is a document presentation format, the specifications for PDF are available on the web. It is a universal format (regardless of which platform and software are used to generate it), compatible with any printer, flexible (you can substitute fonts, add links, bookmarks, notes) and legible onscreen with the appropriate plugins. It can be generated with Adobe Acrobat, with the open source software GhostScript or created on the fly in a Unix environment. * JPEG: http://www.openformats.org/en66 Joint Photographic Expert Group (JPEG) JPEG is one of the most efficient picture compression formats currently available. This open format is very light and allows you to determine the rate of data compression, knowing that the higher the compression rate, the lower the quality of the picture. JPEG follows a process of cumulative compression: the image is clearly affected if you open it and save it with a new compression rate. A variant of this format, progressive JPEG, allows you to optimise the time it takes to display the picture on internet. The new JPEG_2000 standard, currently being defined, will allow for a better quality/compression ratio as well as the indexing of pictures with keywords. * PNG: http://www.openformats.org/en67 Portable Network Graphics (PNG) PNG-8 and PNG-24 are two open formats which are also license-free. They represent the principal alternative to the GIF format, specially created to optimise the display of images on internet. They allow data compression without loss of information and are supported by most browsers. The size of a PNG file remains significantly higher than its JPEG equivalent. However, PNG will advantageously replace GIF for images which are 8-bit or less. * ... -- Bastien
participants (9)
-
Bastien
-
Bowerbird@aol.com
-
Brent Gueth
-
D Garcia
-
Frank van Drogen
-
Holden McGroin
-
joey
-
Jon Noring
-
Marcello Perathoner