On 03/04/08 11:28, John Maddock wrote:

...

By way of experiment I've generated the same equation at various DPI sizes here: http://tinyurl.com/23d74q

I'd be interested in feedback on which is the best size to use in HTML docs

120 dpi is the first one for me where the superscripts aren't fuzzy. (Interestingly, 120 dpi is my screen resolution). 96 dpi is readable, but I have to look carefully. 72dpi is only acceptable as an aide-memoire when I know what it says already. 150 dpi is beautifully clear, but uses acres of screen space. It would be OK for small equations or where there is only one (or a very few) equations on a page (ie detailed explanation of a single function in the maths library). I think 110dpi is probably the best compromise in general. Before acting on the following comment, please bear in mind that I am not a mathemetician, and have no experience with the particular equation. Having said that, I think brackets around the exponents of x and (v2/(v2+v1x)) [read v as 'nu'] would make the equation clearer. -- Martin Bonner Senior Software Engineer/Team Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com disclaimer

Matt Doyle wrote:

...

[mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Tuesday, March 04, 2008 9:28 AM To: boost; Paul A Bristow Subject: [boost] Which DPI size for equations in HTML docs?

By way of experiment I've generated the same equation at various DPI sizes here: http://tinyurl.com/23d74q

I'd be interested in feedback on which is the best size to use in HTML docs (PDF's get rather better looking SVG versions rendered).

Thanks! John.

At least on my monitor (1680x1050) the 120 DPI looks best. The lower resolution images are too hard to read and the 150 DPI just seems to scream at you :^)

Same res, but I'm ok with the 110 dpi. The smaller ones are too hard to read, I'd probably miss something w/o being careful.

110 also looks like the minimum high-readability DPI on my 1600x1200 setup. Zach On Tue, Mar 4, 2008 at 12:23 PM, John Maddock <john@johnmaddock.co.uk> wrote:

...

At least on my monitor (1680x1050) the 120 DPI looks best. The lower resolution images are too hard to read and the 150 DPI just seems to scream at you :^)

Thanks, Matt and Larry.

Screaming is definitely bad ;-)

Any other opinions? John.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Kevin Lynch wrote:

So, I would suggest rendering the images with a large number of pixels (perhaps your 150dpi images), and then relying on the relative scaling attributes in the <img> tags (or css, whichever) to make them the "right" size. Most browsers do a pretty good job of downscaling images when explicitly requested. Then everyone can be happy.

Not a bad idea at all: but I'm not sure how to make that work with the quickbook toolchain. Remember that whatever we do has to rely on automated processing: there are way to many equations in Boost.Math now to mark these up by hand (and then maintain them!) I'm assuming that there is no way to make a selection based on the screen dpi in css? Cheers, John.

Hi, For me 110dpi looks best, both at 1280x1024 with Firefox and at 1024x768 with IE6. Asking the browser to rescale sounds good, but I'm afraid about the results in those browsers that don't do any filtering when rescaling. If I ask IE6 to rescale the 150dpi image to have the same size than the 110dpi one, I get a much less readable result. Bruno

Faik Catibusic wrote:

I saw on home page of project that participation is open and I would like to start working on. This mail is mail for help. (-: Wanting to start but don't know where.

Participate in the discussion. Write patches for bugs you find or enhancements you'd like to see. Submit them here. If you have an idea for a library, sketch it out and submit it for discussion. Boost is open-source. There's no application needed, just results. Sebastian Redl

Martin Bonner wrote:

...

Not a bad idea at all: but I'm not sure how to make that work with the quickbook toolchain. Remember that whatever we do has to rely on automated processing: there are way to many equations in Boost.Math now to mark these up by hand (and then maintain them!) I'm assuming that there is no way to make a selection based on the screen dpi in css?

Well, if there was some way of getting the images marked up as (for example) width='40em', then we can let the browser do the scaling (which would be way cool - it mean the graphics would shrink and grow with CTRL-+/CTRL-minus).

Can you specify an equation width in the source? Would that be too much work?

Well there are 234 .mml files, so I don't want to do it by hand :-0 I guess an automatic method might be possible, as long as the rescaling works well across all the common browsers. John.

On 05/03/2008, John Maddock <john@johnmaddock.co.uk> wrote:

I guess an automatic method might be possible, as long as the rescaling works well across all the common browsers.

Firefox 2 isn't very good at rescaling images, but Firefox 3 should be much better.

Mathias Gaunard wrote:

John Maddock a écrit :

...

By way of experiment I've generated the same equation at various DPI sizes here: http://tinyurl.com/23d74q

I'd be interested in feedback on which is the best size to use in HTML docs

Why not use MathML or something else to have something adaptive to the resolution instead of images?

Oh dear, I knew someone was going to ask me that ;-) The original equations are all in MathML presentation markup, from which I can generate SVG's and PNG's: the former are rendered natively in PDF generation where as no one as far as I know has an FO formatter that handles embedded MathML directly :-( But a more serious issue is how to get the Quickbook/Docbook toolchain to correctly handle embedded MathML, and then generate XHTML that all browsers can read - I didn't exhaustively test this but I could only get Firefox to display MathML if the file had an ".xhtml" extension - the same file with an HTML extention didn't display the MathML. For IE7 it just wouldn't load anything with an .xhtml extention, and of course doesn't display MathML natively anyway. I did find some examples on the net that claimed to work with IE, but whether there's something about my machine I don't know about... they wouldn't display for me in IE7 :-( If anyone has any ideas, I'm all ears! John.

On 05/03/2008, Daniel James <daniel_james@fmail.co.uk> wrote:

MathML. So there's a fair amount of work down that round.

I meant to write, 'down that road'. Not quite sure how I managed to do that... Daniel

On 05/03/2008, John Maddock <john@johnmaddock.co.uk> wrote:

Daniel James wrote:

...

The website also has some information on serving MathML (although their Javascript looks a little dodgy).

Yep, and their author guidelines don't exactly inspire confidence in the whole thing - basically that Firefox requires files to have an .xhtml extension in order to interpret them as such, where as IE simply doesn't know what to do with files of that type :-(

I think the plugin causes internet explorer to accept xhtml documents with mathml, at least when downloading them with the correct mime-type, I'm not sure what it does with local files. It sounds messy, but it apparently works quite well. Coincidentally, it was announced today that IE8 will have better support for namespaces within HTML (not XHTML which it won't support) to give better support for this kind of plugin. But it looks like other browsers are moving in a different direction (at least that's what the HTML5 website seems to suggest) so it doesn't look like it's about to settle down just yet. Daniel