Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Graphics frustration
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Matt Gushee <matt@g...>
Subject: Re: [Caml-list] Graphics frustration
First of all, thanks to all who responded. And I have a few responses
for the respondents. First, though, one general remark: although I am
certainly interested in practical solutions to my current problem, in
this instance I was trying to draw attention to what I see as a weak
point in the selection of available libraries. Graphics are a common
need, and I think better graphics libraries would help the popularity of
OCaml.


On Thu, Jul 24, 2003 at 11:22:03AM +0200, Olivier Andrieu wrote:
>  Matt Gushee [Wednesday 23 July 2003] :
>  > So that's a quick summary of my situation. Do others agree with me that
>  > this is a significant problem? Are there any good solutions in the
>  > works?
> 
> I agree with you that libplot isn't fully satisfactory. I haven't much
> to suggest, though. GD seems to have all the features you need 

I agree. However ...

> (but I
> don't know the state of the ocaml wrapper).

That's the problem. It's far from being a complete GD interface. And
I've contacted its author, and he doesn't expect to continue developing
it. I may see if I can hack in the remaining functionality myself, but
with my minimal C knowledge I'm not optimistic about that.

> One solution I've been
> thinking about is using libart together with Camlimages. Libart is a
> library for rendering vector graphics (e.g. bezier paths) in
> anti-aliased pixel buffers. It's written by the Ghostscipt maintainer
> I think. It seems very good but it doesn't handle text rendering nor
> saving pixel buffers to file. But I think it should be possible to
> interface it with Camlimages : libart would do the primitives
> rendering and camlimages the text rendering and saving.

Interesting idea. I'd like to know if you do that. By the way, what in
particular do you like about libart?

> Writing a C wrapper seems the easiest and quicker way to do what you
> want though ...

I agree, and I actually would like to learn C. But there is so much to
learn, and so little time to learn it ...


On Thu, Jul 24, 2003 at 01:03:01PM +0100, Richard Jones wrote:
> I did something like this in C++ an eon ago. The program generated
> Postscript directly and piped it into Ghostscript to render it into
> the appropriate format. Postscript is a very powerful language for
> this sort of thing once you get used to it.

Well, I'm reasonably comfortable with PS, and that's pretty much the
approach I'm taking already: as I explained, draw with MLgraph, convert
with Camlimages (which uses Ghostscript to load PS). But the problem I'm
having there is that the antialiasing in the output is unsatisfactory.
If I use Camlimages out-of-the-box, there is no antialiasing, and curves
come out looking horribly jagged. On the other hand, if I hack the
Camlimages source such that Ghostscript is called with
-dGraphicsAlphaBits=4, curves look fine, but vertical and horizontal
lines look blurred and semi-transparent. I've also tried converting the
Postscript with ImageMagick, with results very similar to the latter. So
I'm afraid the root cause may be a limitation of Ghostscript, though I
haven't thoroughly investigated yet.


On Thu, Jul 24, 2003 at 02:25:38PM +0200, Daniel Bünzli wrote:
> Dear Matt,
> 
> Did you consider using OpenGL ?

What an appalling thought!

:-)

Seriously, though, I might end up doing this--when push comes to shove I
care more about making things work than about doing them 'correctly.'
Still, as a general solution to the problem of generating 2D raster
graphics, OpenGL strikes me as being an ugly (and perhaps inefficient?)
approach. But I don't understand OpenGL very well, and perhaps I'd
change my mind if I did.

> But it seems that the FreeType library can give you antialiased pixmaps 
> of given fonts and that CamlImages provides an inteface to the FreeType 
> library (never used that however). So maybe you can make both of them 
> interact smoothly. So I suggest you (though I'm completly misinformed) 
> CamlImages+lablGL.

May be worth trying. How mature and stable is lablGL? I would have to
learn OpenGL, and since I don't have much interest in OpenGL per se,
before I take the time to learn it, I'd like to have some assurance that
it is in fact a reliable means for producing high-quality 2D bitmaps.


On Sat, Jul 26, 2003 at 10:37:20AM +0900, SooHyoung Oh wrote:
> 
> What do you think about SVG (Selective Vector Graphics)?

I'm very interested in SVG, but it's not an appropriate solution in this
case. This is a front-end Web application, and I specifically intend it
to render graphics in a form that is viewable with any mainstream
browser--i.e., PNG, JPEG, and/or GIF. I think it will be several years
before we can reasonably expect clients to have built-in SVG support.

> It uses only text for graphics as postscript so it's not difficult to use
> OCaml for SVG.
> If you interested about that, I'll send you a few examples.

If you mean examples of SVG images, I probably have enough already. But
if you have written code for generating or processing SVG, I would be
interested in seeing what you've done.


On Sat, Jul 26, 2003 at 10:55:19AM +0900, SooHyoung Oh wrote:
> 
> SVG (Scalable Vector Graphics)
> 
> sorry...

No worries. There are so many acronyms floating around these days, I
would be a little scared of someone who could remember them all
correctly.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners