I'm a Mac OS X user, who, in order to simply my software use to one editor and one formatter, would like to use XHTML/CSS for everything. Since Opera 8 appears to support the same print capabilites as Prince, and Mac OS X creates PDF files, what are the advantages of Prince vs Opera?

Regards,
Gary

Hi Gary,

To start with, Prince has support for printing functionality that Opera does not have, including:

• Cross-references
• Footnotes
• Page floats
• Page headers/footers that take content from the document
• PDF bookmarks and metadata

Also, Prince can be used non-interactively by other programs; for example it can be called by a script, a web application, or some other automated process that needs to produce PDF files.

It's quite interesting question. I like both products very much. Below are some observation.

Prince supports some parts of CSS3 like CSS3 selectors (for web browser it's harder to implement CSS3 selectors as some of them undermine incremental rendering), paged media, generated content (cross references!), line (partial) that are not supported by browsers including Opera. Also Opera has some printing related bugs that make it less convenient for printing purposes. Prince resolves entity references declared in external DTDs while Opera ignores external DTDs (downloding DTDs would slow down rendering of web pages).


Prince produces PDF immediately so I usually run it directly from my text editor using comand line options. This is both advantage as PDF is widely used format and we lacked PDF oriented CSS formatter and disadvantage as Prince is tied to PDF format and implies Acrobat Reader to be installed.

From another hand Opera has full CSS2.1 support (modulo bugs of course) that Prince does not have yet. Opera fully supports XHTML 1.0 while in Prince it is limited (it recognises IDs, classes and hyperlinks and applies default CSS style sheets) but sufficient for printing purposes.
Opera supports multiple CSS media types (screen, print, projection, handheld, aural/speech), Prince is focused on print media (where it performs better then Opera). Opera supports EcmaScript, DOM and XML events that prince does not (and probably should not). Opera perfoms glyph by glyph font switching (so if some glyphs are missing in font Opera will substitute another font) that is not done yet in Prince (but Prince reports missing glyphs). So if Opera would implement CSS3 paged media module and fix printing related bugs then it would be simply invaluable browser.

One correction: Prince 5.0 does perform font resolution on a character by character basis.

This means that you can for example specify a Greek font and a Japanese font in your font-family and then intermingle Greek and Japanese text and Prince will use the correct font for each character.

If you see any "missing glyph" errors, it is because none of the fonts specified in the font-family contained glyphs for the character that you have used.

(The default serif and sans-serif fonts map to Times New Roman and Arial respectively, which do not support all of UNICODE).

Yes, now I realise that this was my fault as I did not specify all necessary fonts in font-family. I did not notice it in my browser as Opera searches whole font database not just those specified in style sheet and default font options. But I think web is different media and for Prince current implementation is probably preferable, otherwise it would be hard to track what fonts are actually used in real output.


But it seems that one can change defaults via fonts.css

@font-face {
    font-family: serif;
    src: local("Times New Roman"), local("Times"), local("OpenSymbol")}

By the way, Prince 5.0 has a --verbose option which will list exactly which fonts are used to format a particular document; it's handy for debugging.


Yes, this is a mechanism that allows you to customise the default font families