SVG queries

Is there a reason why the extents in the SVG graphics functions are given as integers, while the routines to create SVG graphics in FTN95.CHM use the D form (i.e. coordinates in DOUBLE PRECISION)?

For the %pl users, does %pl[native] work with SVG creation?

Eddie

Eddie

The extents provide the dimensions of a graphics region so are naturally integers.

You can use the drawing routines with or without the D.

The coordinate data is written to the svg file as floating point values which is presumably what the svg standard stipulates.

The drawing of a native %pl cannot be redirected to an svg file. Unfortunately it would be a major task to add this functionality.

Paul,

I'm glad I asked (about %pl) - it saves someone else asking it!

Eddie

This is a statement of the obvious, or rather, statements of the obvious.

Suppose one has a routine (say subroutine DRAW) that draws something in a %gr area, with dimensions ix, iy. The original drawing primitives using pixel coordinates are used. Given a respectable size monitor, the results might be 'not bad'. If one then redraws the object, using DRAW, on a hard-copy device such as a printer, where the effective dpi is much higher (say 600 instead of 96 for the screen, giving 6000 pixels over 10 inches instead of (say) 1000 pixels across the screen), then the results are much better.

Now say DRAW is invoked to create an SVG file. If the limits are set to ix,iy, (i.e. DRAW is called again after a file is opened to write the graphic as an SVG file) and the resulting SVG image is examined, then as every coordinate is rounded to the nearest pixel, when examined enlarged the results are disappointing. They are less disappointing if the SVG limits are set to 10ix, 10iy, as one might expect. But they still show the effects of rounding to the nearest pixel.

If an SVG file is created using the newer graphics primitives that use REAL*8 coordinates, the results are significantly better again. But, they are never better on screen as there is that rounding to pixels. i.e. always use the new primitives.

Very obvious really.

I'm not entirely sure that the extents are naturally integers, but then the point of a scalable drawing is that it is scalable, I suppose.

The SVG creation is excellent, by the way. However, the method of opening the file does not allow for the normal Fortran approaches such as STATUS='NEW', and you have to take care not to overwrite something previously generated. But then that's obvious too.

Eddie

J-S: I hadn't thought about line thickness in a pixel world, but there's a serious point there.

For many years I used HPGL as a metafile format, but that is pixellated if you like, because everything is done in 1/4 mm steps (or 1/100 inch - it depended on what device you used), but line thicknesses weren't if the hard copy actually used a physical pen. Really long vectors aren't all that bad if the ends are out by a half pixel, but short ones can be.

My point is that if you use the SVG file option you have to preset the coordinate range to be much bigger than you get for on screen pixels in order to get a result that is even slightly scalable. Whether one needs REAL*8 is moot - the SVG files created by Clearwin's new facility are written with 2 decimal places, and ultimately that means that they are 'pixelated' at 1% of the units used to define the extents of the plot.

I'm not sure that the errors are cumulative as per the example (although I get that the analogy is stretched), they are never more than a half pixel when one uses pixels for coordinates (provided one rounds rather than truncates).

Eddie

are the values real or the truncated integer 'pixels' values then ?

No, they are proper decimal values, but to 2dp. But they have to be REAL*8 in a program.

With a screen, you are stuck with pixels (hopefully 'stuck pixels' is a thing of the past).

As integer arithmetic in Fortran rounds down, you always need to add 0.5 to a computed position even if using the 'D' version of the CW+ graphics primitives when plotting on a large pixel device like a screen.

I think that your demo shows the effects of pixel roundoff pretty well.

Eddie