How can I render Math equations on the web? I am already familiar with LaTeX's Math mode.
The other answers are out-of-date. As of 2012, beautiful math is easy to write and render. The technology is called MathJax. You can see it in quiet action on MathOverflow and hundreds of math blogs.
MathJax is an open source JavaScript display engine for mathematics that works in all modern browsers. No more setup for readers. No more browser plugins. No more font installations… It just works.
Mathjax is reliable and unobtrusive, so you just need to write the math. You do so in Tex (Latex), a concise syntax with which most scientists and mathematicians are familiar (and have shared decades of good tutorials). For Mathjax, you simply write Tex code in-line in your HTML between double dollar signs, eg.
When $$a \ne 0$$, there are two solutions to $$ax^2 + bx + c = 0$$ and they are $$x = {-b \pm \sqrt{b^2-4ac} \over 2a}.$$
To use Mathjax to render your math, put a Javascript line in your HTML header:
<script type="text/javascript" src="http://cdn.mathjax.org/mathjax/latest/MathJax.js"></script>
If you publish on a platform such as Wordpress, Tumblr or Blogger there are plug-ins in their galleries to do this (Wordpress).
How does Mathjax render math? With Javascript it renders your math to beautiful HTML and CSS (remarkably resembling Latex) in a fraction of a second. If a browser supports MathML, it can render math through that too, but that's not important. It's a popular success because the end-user workflow is easy, not because of the technology behind it.
You can choose to use Mathjax (over png images) on Wikipedia if you have an account. Look for Special:Preferences / Appearance.
MathML is ridiculous. It's neither human-readable nor human-writable (the quadratic equation takes 800 characters - it's 50 in Tex). It's just another pointless XML language . Thankfully, it's obsolete before most browsers support it. It doesn't even look as good as Tex or Mathjax's HTML-CSS!
It turns out this is a bit of a pain.
You can use MathML, but browser support is still iffy. If you are starting with latex you've got a few options for converting to html, but they'll all typically end up rendering the actual equations to images and inlining those.
Nothings all that pretty (unless you resort to pdf or something). What's best will depend a bit on what sort of content, how many equations, and how complicated the equations are.
Here is a decent summary.
My two favorite approaches:
Client-side: MathJax. See some examples here. It is very easy to use and install and its development is backed by the AMS and SIAM among other scientific institutions. I expect this to become the defacto standard for displaying math on the Web.
Server-side: LaTeXML. This is used for producing the NIST Digital Library of Mathematical Functions. It tends to hiccup if you have custom macros in your TeX sources but in general it does give very good results.
The jsMath package is another option that uses LaTeX markup and native fonts. Quoting from their webpage http://www.math.union.edu/~dpvc/jsMath/:
The jsMath package provides a method
of including mathematics in HTML pages
that works across multiple browsers
under Windows, Macintosh OS X, Linux
and other flavors of unix. It
overcomes a number of the shortcomings
of the traditional method of using
images to represent mathematics:
jsMath uses native fonts, so they
resize when you change the size of the
text in your browser, they print at
the full resolution of your printer,
and you don't have to wait for dozens
of images to be downloaded in order to
see the mathematics in a web page.
There are also advantages for web-page
authors, as there is no need to
preprocess your web pages to generate
any images, and the mathematics is
entered in TeX form, so it is easy to
create and maintain your web pages.
See for example this page or that one.
Katex
A couple of developers from the Khan Academy released a blazing quick library based off of Tex called Katex:
Fast
High-quality
Self-contained; and,
Can be rendered on the server
Looks like a great modern option.
You can do more math directly in HTML than most people realize. See these notes.
The only safe way to render LaTeX is to save the output as an image. Some sites try to use tools to do this on the fly, and they never work reliably. For example, on some blogs, this works if you visit the web page directly but not if you go through Feedburner/Google Reader.
I've had terrible experience with MathML browser support, both in Firefox and IE. Don't even try it. Not yet. Maybe in a few years.
Here's the site I use to compile LaTeX to gifs.
If you're willing to use PDF instead of HTML, things get much easier. Just create your LaTeX document and use pdflatex to compile it to PDF. If you do go the PDF route, you may be interested in how to include PDF properties such as author, keywords, etc. in your LaTeX file. Also, this page explains how to mark up the LaTeX to make links in your PDF.
texvc can convert LaTeX math equations to png or HTML.
LaTeX and MathML are the only "right" ways to do this. However each has severe limitations. The other options are images (not really optimal if you need to edit the equations later) or complex HTML(requires some training but can be done).
I do render LaTeX formulas "on demand" in my wiki. Basically, I extract the latex code from each wiki section and put it into a .tex file (whose filename is an md5sum of the latex, so if the same code is used again, the same tex and therefore the same image will be used).
The tex file is then latex compiled by a cron task every minute, to produce first a .ps, then with the convert program a .png (named again with the original md5). The wiki entry replaces the latex text with an img tag referring to this png (with the original latex code as an alt, for text readers).
If you want to go this way, be very careful to sanitize your latex as much as you can. there are commands in latex, like \input, that you definitely do not want to let go through, as anybody able to use them would be able to include any readable file in your server disk and include it in the resulting latex output.
To solve this issue, Mediawiki (of wikipedia fame) has a special plugin which sanitizes the latex input, but I didn't want to use it for two reasons: first I did not use mediawiki, second it's written in OCaml and I didn't want to mess with a language I don't know.
I've used ASCIIMathML for this in the past. It's essentially a JavaScript library and can use a plugin in IE to optimize performance, but also works without it in IE & Firefox/Mozilla (although a bit slower). The syntax supports a subset of LaTeX, but the differences cause some confusion, so it may confuse your users, depending on where they are coming from.
Here are some links so you can check it out yourself:
ASCIIMathML
ASCIIMath Tutorial
Not perfect and doesn't work in all browsers (Safari, etc) but it's something that works today at least, albeit in a somewhat selective subset of the web.
I've written an open source javascript module to do this, named jqmath. See http://mathscribe.com/author/jqmath.html. You type equations in a simplified TeX-like syntax, and jqmath converts them to MathML or simple HTML and CSS, depending on the browser. This is more efficient and accessible than using images.
By the way, some of the summaries and notes mentioned in the other answers here are pretty outdated now. Also, Firefox supports MathML now, and webkit (Chrome and Safari) have it in their nightly builds, though they haven't released it yet. Internet Explorer renders MathML if you have the MathPlayer plugin. Opera fakes MathML with a stylesheet. MathML is part of the HTML 5 standard, so presumably all these browsers will natively support it sooner rather than later. It's true that until then, jqmath's output will not look as good as TeX's, but it's certainly readable, and is definitely a better solution for web pages going forward.
If you do use images, will a reader for a blind user be able to read the equation? Some may want to.
There is a little Mac App called LatexIt that makes it very easy to convert LaTeX equations to PDF, PNGs etc.
(I use it to create equations for my slides in Keynote or PowerPoint. It's very nice, with drag 'n drop support, so you can just 'drag' the equations anywhere to insert them.)
I have the impression that MediaWiki will allow you to enter LaTeX markup (or something similar) and dynamically decide the best way to display it. Currently I think that uses HTML where possible for small expressions and images for more complicated expressions that cannot be represented otherwise; I suspect that one day it may take advantage of whatever other methods become state of the art, i.e., MathML if browsers start supporting it. So I think you might find that if you use MediaWiki as if it were your website engine you'll be forward-compatible with whatever comes in the future.
You can generate equation image on-the-fly via a LaTeX server.
http://www.forkosh.com/mimetex.html
If you are using WordPress, you can use LaTeX for WordPress (http://wordpress.org/extend/plugins/latex/) plugin.
Currently the state of client side MathML rendering isn't ready for broad adoption. The means you really need to render the MathML as an image. How you do this will depend on your environment.
Do you have root access to your own server? Are you comfortable installing software on it? In this case, you can render your own images. If your running blogging software or a wiki, generally you can find a plugin which will take advantage of your platforms capabilities. This is usually the idea scenario if you plan to write a lot of math expressions.
If you host your own images, you can either pre-render them, or use an extension like mimetex.cgi. If you allow arbitrary MathML expressions to be rendered, you run the risk of other websites hot linking to your image renderer. If you put a filter in on your web server to prevent hot linking, then people viewing your site through a feed reader will also be blocked.
If you can't render your own images, or if you only have a few expressions you want to render, then you can usually have another service generate the image, and you hot link the image on your site. The downside of course is your dependent on another site, who gets nothing in return for serving up images for you.
Examples of other services (as mentioned in other comments) include:
* http://www.artofproblemsolving.com/LaTeX/AoPS_L_TeXer.php : alt text http://alt2.artofproblemsolving.com/Forum/latexrender/pictures/a/f/c/afc183343d84d030898f589bac12a8d9cf04558a.gif
* http://www.forkosh.com/mimetex.html : mimetex.cgi http://www.forkosh.dreamhost.com/mimetex.cgi?c=%5Csqrt%7Ba%5E2+b%5E2%7D
The advantage of using mimetex is one can easily change the formula and have it re-rendered.
Related
It seems the most common aproach to web design is to use HTML/XHTML & CSS in conjunction with other technologies or languages like Javascript or PHP.
On a theoretical level, I'm interested to know what other languages or technologies could be used to build an entire site without using a single HTML tag or CSS style for styling/positioning?
Could a website be made only using XML or PHP alone, including actual styling and positioning?
Presumably Flash sites are till embedded in HTML tags?
Thanks
There are actually several solutions that allow you to nearly completely avoid CSS and HTML.
GWT: Google Web Toolkit
Written in Java and will allow you to build both server and client code in Java. Used to build Google Wave.
Cappuccino and Objective-J:
Objective-J is to JavaScript as Objective-C is to C. It extends JavaScript with many near features, including type-checking, classes and types.
Cappuccino is like Cacoa (Mac OS X GUI toolkit).
Using these two you can build incredibly rich and desktop like webapps. They run mostly on the client side and you can use whatever you want on the server.
A good example is 280slides
SproutCore is similar to Cappuccino, but it uses pure JavaScript instead. Apple is using SproutCore to make me.com.
I should also mention that knowledge to HTML, CSS, JavaScript is a good skill to know, just like understanding your compiler is a good skill.
EDIT:
As said above Adobe Flash can also be used.
You can make a website with out a single html tag. Just give folder read access to all your directories, have sensible file names. From here you user will be able to browse images , read text files, download videos and depending on the content he may or may not come back ever again, but you do achieve the goal of setting up a "website" with out a single line of html or css or any other code for that matter.
:-) :-) :-)
You can host a telnet server with anonymous access and a specialized shell that restricts the user to doing whatever it is you want the site to do. ;)
Lets make the distinction between what is required by the web browser, and what you as a developer use to create that markup.
Remember that HTML nowadays is xml. You could use any markup language you like and convert that to HTML using XML.
eg ASP.NET uses markup such as which is converted on the server to .
As long as the content going down the wire to the browser is HTML, or generates HTML through script, you can use any approach you like.
However these approaches have mostly failed as developers prefer having direct control over the markup. It makes css as well as scripting much easier when you are certain what the html is going to be.
ASP.NET MVC is a product created in response to criticisms leveled at the ASP.NET webforms model.
Also, this is another answer because it's a completely different technology, but you can write an application in XUL and it'll run in Mozilla-based browsers without any HTML.
There's also XML. You can create websites with XML only. A well known one is World Of Warcraft. Check the page source. An XSL is used as stylesheet. There exist even XML based web frameworks like OpenLaszlo. You can let it serve either DHTML or Flash on reqeust out of a single XML template.
The Wt C++ Web Toolkit.
You can write your web application in C++ using Qt-style widgets (input boxes, buttons, tabs etc) and hook up client-side events to C++ code on your server. All without writing any HTML or CSS.
A sample application from their website (you may also want to look at this excellent tutorial):
HelloApplication::HelloApplication(const WEnvironment& env)
: WApplication(env)
{
setTitle("Hello world"); // application title
root()->addWidget(new WText("Your name, please ? ")); // show some text
nameEdit_ = new WLineEdit(root()); // allow text input
nameEdit_->setFocus(); // give focus
WPushButton *b = new WPushButton("Greet me.", root()); // create a button
b->setMargin(5, Left); // add 5 pixels margin
root()->addWidget(new WBreak()); // insert a line break
greeting_ = new WText(root()); // empty text
/* when the button is clicked, call the 'greet' method */
b->clicked().connect(this, &HelloApplication::greet);
}
void HelloApplication::greet()
{
/* set the empty text object greeting_ to greet the name entered */
greeting_->setText("Hello there, " + nameEdit_->text());
}
Curl (requires a browser plugin)
Wikipedia article
A webpage looks like this:
{curl 1.7 applet}
{value
let b:int=99
let song:VBox={VBox}
{while b > 0 do
{song.add b & " bottle(s) of beer on the wall,"}
{song.add b & " bottle(s) of beer."}
{song.add "Take one down, pass it around,"}
set b = b - 1
{song.add b & " bottle(s) of beer on the wall."}
}
song
}
Source
Since browsers view HTML, I'm assuming you mean create a site without ever having to edit/write HTML/CSS. The framework/app environment/whatever taking care of everything for you - yet still allowing you control over the presentation layer.
Seems like that is certainly possible on a theoretical level.
I ran across Noloh (not one line of html) a while back. Was intrigued, but never actually tried it out.
From various places on the Noloh site:
Because NOLOH does not rely on HTML or pages, maintaining complex rich Internet applications is significantly easier than with other methods.
Developing applications with NOLOH only requires using a single, unified language: a superset of PHP that completely maintains all aspects of server-client communication for you!
I think you could build a site entirely in SVG.
The front page of emacsformacosx is almost entirely SVG, for example.
Downsides: It wouldn't be viewable in IE (at least through version 8). And last I looked, text support, like flowing and justification, was weaker in SVG. (You could embed HTML inside an SVG element when you needed sophisticated text features, but that would violate your no-HTML rule.)
You'd probably still want to use CSS with SVG, because it's a good idea there for the same reason it's a good idea with HTML, but it wouldn't be necessary.
A website is always viewed through a browser (at least always if you are human :)). Browsers understand HTML. Whatever the technology - you have to basically render HTML. Even in cases with rich technologies like flash, the flash object that is rendered by a browser plugin is embedded inside the HTML.
In theory it is possible to do it without HTML, but the question becomes how much does the product diverge from the definition of a website...
One really short, simple answer... you can't :D
Flash requires an embed tag, an image requires an embed tag etc, so you'd have to use HTML in some method or another.
PHP is an embedded language, it is used to generate HTML on which the browsers renders, with XML, well technically a browser like Ie or FireFox will render it in it's own way for readability, but I would not class that as a website.
The major developments in the world of web technologies involves the development of HTML and CSS to improve them, there isn't any need for an alternative. In fact we're pushing towards a standard, what point would there be in introducing a new language to negate these standards. The whole IE saga would simply get worse.
Like the others have suggested, you could directly load an image or a flash file, but an image is useless on it's own, and a flash interface throws up loads of problems like SEO, accessibility etc, not least it's very heavy and usually completely misused. In my mind I wouldn't even class this method as a website, it just doesn't tick any of the boxes (IMO).
I think you can have an URL pointing directly at a hosted Flash (SWF) file, I've certainly done this though I don't know if all browsers work.
Anyhow, I tested this when developing MyDinos.
e.g: http://mydinos.com/home.swf
You can use Emscripten and its SDL subset.
You could try using quickstatic. You can code HTML templates from Python3. What is super cool about it is the fact that if you put in a for-loop for a certain item, you can generate that many items (maybe even use it to print items from a directory or quickly serve thousands of links).
Why HTML/JavaScript/CSS are not becoming compiled languages (or maybe even merge into a single compiled language)? What if browsers were running "Browser Virtual Machine" and html/javascript/css sources could by compiled to a "browser bytecode". Wouldn't it help developers and users a lot?
I can see a few challenges:
What to do with zillions of existing pages? Make this compilation optional, so if you want you can use plain old html. If you want to feed a browser with a compiled page just use .chtml for example.
How search providers would index pages? Make a decompiler that would decompile bytecode into exact original sources (for example like flash can be decompiled). Or search providers can use the same virtual machine and get data they need from there.
How to make it compatible with all browsers? Have one centralized developer (lets say w3c) to develop this virtual machine and then each browser would embed it.
But what about benefits:
Speed.
Size.
No more "loose" and "half-correct" html. It is either correct or won't compile.
Looks the same in every (supported) browser.
If not a bytecode then at least have some native compression going on, html probably is not the most efficient way of data storing. I know there is gzip but why to compress pages every time on a server and decompress in a browser if we can compress it once and feed it to a browser?
So what stops us from taking this road (well, besides a huge amount of effort to make it all happen)?
Ah, but Javascript IS becoming a compiled language. Check out Firefox 3.5 with TraceMonkey. It's insanely fast compared to um you-know-who's browser. It's true that JS will never be C, but it's a much more dynamic language than C is, and in many ways that makes it more expressive and powerful.
As far as HTML goes, I don't think that the lack of validity of HTML is a huge detriment to speed. I think the engines that put together the visual representation and manipulate the DOM need to get a lot better (um, IE, I'm looking in your general direction...). CSS compliance needs to get better, and CSS itself needs to get more powerful. (Get on the bus with CSS 3 people!)
But I do think that speed is going to get better on Firefox and Chrome to such an extent that people really ARE going to start using it for mainstream application development. It's funny. Adobe seems to be selling Flash as their platform for dynamic web content, MSFT is selling Silverlight for dynamic web content, and Google just wants to really improve HTML and Javascript to display dynamic web content. And Google's doing pretty well at it so far, I must say...
Your ideas have validity when they are applied to JavaScript. As others have noted, to one degree or another several vendors are trying to apply those principles to JS even now. Another big step in this area will likely be the Chrome OS Google has announced. However, when it comes to (X)HTML and CSS I think your ideas may be missing the point.
The world wide web is not a buggy and inconsistent application platform but a massive and unprecedented collection of interconnected documents. The power of the web is in the abstraction of the data from the often rigid (and breakable) visual layouts and increasingly complex in-page functionality largely provided via JavaScript. Encoding these pages in (X)HTML is ideal for making them accessible to the widest possible audience both in terms of browsers and in terms of technical knowledge required to author a page.
More and more the web is being used as an application platform - which is a powerful and exciting use of this technology - but we cannot lose sight of the fact that these Ajax-driven "web 2.0" apps are merely documents with extended functionality. Compilation doesn't make sense for a document and compression is already happening (via gzip and the like).
On a more practical note, the W3C moves at a glacier's pace and browser vendors take turns between jumping-the-gun supporting experimental features in unfinished specs and taking their sweet time supporting other specs which have been on the table and in common usage for years. The whole processes is like herding cats. I wouldn't hold my breath for them to make the kind of radical changes you're proposing any time soon.
Since HTML and CSS aren't code they can't be compiled. Google Chrome's V8 engine does actually convert JS into byte code, expect other rendering engines to follow suit!
http://code.google.com/apis/v8/design.html
We recently reworked a php template system I've helped create to use minify to compress multiple JS and CSS into one file each, seeing our file sizes drop to about 20% of the origial combined sizes. Minify also does gzip and caching so it's really amazing for speeding up websites.
http://code.google.com/p/minify/
In short you can't compile non-code, which HTML and CSS are. JS can be compiled and is starting to be, but all depends on what browsers feel like doing.
Browsers just need to be on the ball regarding supporting web standards. The more browsers do this, the less headache us web developers have. I was quite happy with YouTube's very public drop of support for IE6. We need more action like that for the web to move forward.
The V8 javascript engine (also embedded in Google Chrome, but it's open-source and liberally licensed so you're welcome to use it in the next browser you write!) does compile Javascript to native machine code -- of course, it does it "just in time" (like most modern compilers -- Java, C#, etc!), not "ahead of time" (like Fortran did in 1954 when computers were just too weak to handle compilation in the midst of execution). I'd be surprised if other good JS engines, like those in the very latest Firefox and Safari, didn't do the same.
Looks like you're not advocating "javascript as a compiled language" (since it obviously already IS compiled, if you're using a good JS engine), but rather "ahead-of-time" compilation for it (just when most modern languages are essentially abandoning ahead-of-time compilation). Pushing machine code rather than compilable code down the wire sounds like a mostly horrible idea -- much larger size, difficulties in supporting one CPU vs another, security nightmares in properly sandboxing it, etc, etc) with not much in term of compensating benefits.
That said, if you're really keen on pushing machine code to the client, try out nativeclient (as long as the client is an x86 machine - forget every smart phone on the planet, many netbooks, good old macs, etc) -- at least it promises a fix to the security nightmares. If and when you're happy with nativeclient, transforming a just-in-time compiler into an ahead-of-time one is a far easier technical challenge (if you want to keep using Javascript for the sources rather than other languages, of course).
See here for a previous discussion on the matter
Not all of the reasons given are necessarily valid, but one important one is that, unless you're Google, server-side CPU cycles are a lot more valuable than client-side cycles: so it's easier to have the client compile/optimize what is quite often dynamically generated HTML/JavaScript, rather than the server.
Ken
Speed.
You're assuming that it takes significant time to parse HTML. However it might be that that time is insignificant compared to the time required for something else, e.g. the time required to layout the text on the end-user's window.
No more "loose" and "half-correct" html. It is either correct or won't compile.
You already get that, using [X]HTML.
Looks the same in every (supported) browser.
You seem to be saying that there should only be one browser, or that all browsers would support it equally.
Internet standards don't happen by having a single body (the w3c) implementing something and declaring it a standard. Instead, internet standards happen by having multiple independent bodies creating multiple implementations. A consequence is:
Some people have developed something that isn't standard yet (i.e. they're ahead of the standard)
Some people haven't yet developed something that is standard (i.e. they're behind of the standard)
I think your idea is sound, however there's still no way to enforce a standard. Thus if there was a non-supported feature, there's a good chance the entire page would simply not display anything. In the current setup, critical information can still be passed.
Google V8, which is one of many new-generation javascript engines 'compiles' javascript into pseudocode, much like .NET 'compiles' c# on the fly. Nothing magical here. Expect more of it esp. as webapps get heavier and more demanding
HTML
HTML is pretty much XML. DTD'd exist for various versions and developers can check against that at any time.
CSS
CSS is not a programming language, however I do agree that "compiled" CSS could work seeing as compilation would compress it. However with the support that CSS has and with the number of essential hacks any CSS needs to have, you'd never manage to compile it without errors.
JS
As others have mentioned, JS IS becoming a compiled language except the browser compiles it for you and not you yourself.
Does anyone have any suggestions on how to generate accessible PDFs (including images) from HTML?
The PDFs need to look like the original HTML, including positions of images etc.
Any special HTML structure required to help make the final PDF accessible?
I've seen questions about creating PDFS none of them specifically address the important issue of accessibility.
My poison of choice is Perl but references to any program, language or library will help.
I have a more in-depth question at TypeDoc if anyone has more general information to offer.
http://doctype.com/TiB
Also,
I, and others, would find it useful if users with accessibility problems could comment if they find the "usability experience" of using PDFs better or worse than reading from Plain Old Semantic HTML (POSH).
Thanks
Mike
Look into PrinceXML. Through CSS you can control margins, page breaking and orientation. While not open source, you can try it for free, but it places a small water mark in the upper right corner.
The Adobe ColdFusion server product does a really fine job of this, not surprisingly. But it's not free, and the open source implementations of the language (Smith and BlueDragon) don't support the pdf stuff.
Developer licenses to Adobe ColdFusion are free, and you can download it.
I've done this thing on a small scale but scripting Safari to print to PDFs. I don't recommend it for large-scale projects though.
By far the most capable PDF publishing tool I've ever come across is reportlab. There is an open source library written with Python and a proprietary system that allows you to construct a document using RML, a custom xml spec. The latter is easier for more complex docs. They tend to be very flexible (and reasonable) with pricing.
Not strictly an answer to your question as it doesn't handle html-to-pdf conversions, but perhaps of use to you.
In my Delphi program I want to display some information generated by the application. Nothing fancy, just 2 columns of text with parts of words color-coded.
I think I basically have two options:
HTML in a TWebbrowser
RTF in a TRichEdit.
HTML is more standard, but seems to load slower, and I had to deal with The Annoying Click Sound.
Is RTF still a good alternative these days?
Note: The documents will be discarded after viewing.
I would vote for HTML.
I think it is more future oriented. The speed would not concern me.
The question of HTML or RTF may be irrelevant. If they are just used for display purposes, then the file format doesn't matter. It's really just an internal representation. (Are any files even being saved to disk?) I think the question to ask is which one solves the problem with the least amount of work.
I would be slightly concerned that the browser control is changing all the time. I doubt the richedit control will change much. I would lean towards the richedit control because I think there is less that could go wrong with it. But it's probably not a big deal either way.
Have you considered doing an ownerdraw TListView?
I'd also use HTML. Besides, you just got an answer for the clicking sound in TWebBrowser.
If you'd rather not use TWebBrowser, take a look at Dave Baldwin's free HTML Display Components.
I would vote for HTML, too.
We started an app a while ago...
We wanted to
display some information generated by the application. Nothing fancy, just...
(do you hear the bells ring???)
Then we wanted to display more information and style it even more....
...someone decided, that RTF isn't enough anymore, but for backwards compatibility we moved on to MS Word over OLE-Server. That was the end of talking about performance anymore.
I think if we would have done that in HTML it would be much faster now.
RTF is much easier to deal with, as the TRichEdit control is part of every single Windows installation, and has much less overhead than TWebBrowser (which is basically embedding an ActiveX version of Internet Explorer into your app).
TRichEdit is also much easier to use to programmatically add text and formatting. Using the SelStart and SelLength, along with the text Attributes, makes adding bolding and italics, setting different fonts, etc. simple. And, as Re0sless said, TRichEdit can easily be printed while TWebBrowser makes it more complicated to do so.
I would vote RTF as I dont like the fact TWebBrowser uses Internet explorer, as we have had trouble with this in the past on tightly locked down computers.
Also TRichEdit has a print method build in, where as you have to do all sorts of messing about to get the TWebBrowser to print.
Nobody seems to have mentioned a reporting component yet. Yes, it is overkill right now, but if you use it anyway (and maybe you already have got some reporting to do in your app, so the component is already included) you can just display the preview and allow to print / export to pdf later, if it makes any sense. Also if you later decide that you want to have a fancier display there is nothing holding you back.
If both HTML and RTF won't satisfy your need, you could also use an open source text/edit component that supports coloring words or create your own edit component based on a Delphi component.
Another alternative to the HTML browser is the "Embedded Web Browser" components which I used a few projects for displaying html documents to the user. You have complete control over the embedded browser, and I don't recall any clicks when a page is loaded.
I vote for HTML also
RTF is good only for its editor, else then you'd better go standard.
RTF offers some useful text editing options like horizontal tabulator which are not available in HTML. Automatic hyperlink detection is also a nice extra. But I think I would prefer HTML, if these features are not required.
I vote for HTML.
Easier to generate programmatically.
Widely supported.
Since you don't need WYSIWYG capabilities I think HTML advantages trump RTF. Moreover, should the need to export generated data for further, WP-like editing arise, remember that major word processor can open and convert HTML files.
Use HTML, but with 'Delphi Wrapper for Chromium Embedded' by Henri Gourvest , Chromium embedded uses the core that powers Google Chrome.
Don't use TWebBrowser, I'm suffering from all programs that use IE's web control - the font is too small on my 22' monitor with a 1920x1080 resolution, I use Windows 7 and my system's DPI is 150% (XP mode), I tried everything to tweak trying to fix that, no luck...
There is a standard two-pass algorithm mentioned in RFC 1942: http://www.ietf.org/rfc/rfc1942.txt however I haven't seen any good real-world implementations. Anyone know of any? I haven't been able to find anything useful in the Mozilla or WebKit code bases, but I am not entirely sure where to look.
I guess this might actually be a deeper problem with having to actually render HTML (the contents of table cells) but just to keep it simple - plaintext HTML table as an image. Even an HTML table rendering algorithm ignoring the "as an image" part...
If a commercial tool is an option, look at:
HtmlCapture ActiveX Control V2.0 (originally named HtmlSnap)
Some features they claim:
By calling SnapHtmlString(), you can take a snapshot for a html string.
Get snapshot images rendered by either Microsoft IE or Mozilla Firefox.
Just by calling SnapUrl() and SaveImage(), you can take a snapshot of a webpage into various images, such as BMP, JPG, JPEG, GIF, PNG, TIF, TGA and PCX.
Convert html to vector image format like EMF and WMF.
Self contained ActiveX control with no third party dependencies.
Support custom gdi output of the resulting image.
Support saving resulting image both to file and in memory.
Support saving both full-size web page and thumbnail one.
Take a snapshot of a whole webpage into one image without scrollbars.
Make grayscale or B&W images with efficient algorithms to keep the quality.
Support JPEG compression level, compression method selection of TIFF and GIF.
Support setting color depth in images while keeping the quality of the image as much as possible.
Selectively save activeX, image, java applets, scripts and videos on a web page as you want.
Send custom cookies, http headers, credentials in snapshot requests.
Take snapshots of webpages via a Proxy server.
More than 30 samples written in VC, C- , Delphi, VB, C++ Builder, Java, JScript, Perl, VBScript, ASP, ASP.net and PHP are provided.
html table rendering is non-trivial due to the various ways that the sizes of the cells may be specified, tables nested within tables, etc.
if all you want is the image, a simple solution would be the .NET browser control (which is basically the COM component for IE) and a screen-capture function
if you want to get some source to manipulate, the Mozilla source should still be available
I'm not sure if this will meet your constraints or not, but you can try using IE or an IE control with MSHTML and the IHTMLElementRender interface to render the table to a device context.
If you have XHTML, not plain HTML, you should be able to retrieve the content of those cells along with information about the table's structure: colspan, rowspan, etc. Using this information, you can render the table using your own border, padding and margin values.
Things get complex when you also want to render the user defined dimensions. But for retrieving the table data and drawing it, you could use an XML parser. PHP's parser is here: http://ca3.php.net/xml
One tool that comes close is: http://www.terrainformatica.com/htmlayout/main.whtm
This library offers a way to capture rendered HTML to an image, however it is not open source (but free!). Hope it is useful to some!
Unfortunately my app is cross platform, C/C++ with no MFC or platform dependencies (nightmare!). I'm hopefully looking to find a general purpose algorithm for table rendering. I think the 2-pass option from the RFC comes pretty close so I'm probably going to just dig in and work against that. I'll be sure to blog about it and post my eventual solution here if I can!
Take a look at Prince XML - it's a commercial tool to render CSS-styled XML (including XHTML) documents to PDFs. This tool is conform with major W3C standards such as XHTML and CSS2.1. You can try the free demo version from their Homepage!
Since you want an image: It shouldn't be a big problem to convert the generated PDFs programatically to an images.