forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

SVG queries

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Dec 20, 2017 2:10 pm    Post subject: SVG queries Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Dec 20, 2017 2:40 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Dec 20, 2017 3:27 pm    Post subject: Reply with quote

Paul,

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

Eddie
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Thu Jan 18, 2018 2:33 pm    Post subject: Reply with quote

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 10*ix, 10*iy, 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
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Fri Jan 19, 2018 3:32 am    Post subject: Reply with quote

SVG are scaled vector graphics aren't they (obviously) which means that they can be scaled without loss of precision/definition.
If the co-ordinates are rounded initially then any 'scaling' later will multipy that error. In the case of the screen to printer example given by Eddire above by a factor of x10 - so , and especially for curved lines/surfaces of primitives one would obviouly expect degradation.

Shouldn't SVG files be written with the full, non-truncated (for cėscreen) co-ordinates and then truncated at each useage for screen display or printer output, as a function of relevant resolution ? That's why the SVG co-ordinates are real no ?

It'0s just like adding up a large number of data values which have been limited in their 'accuracy' to a certain number of decimal places, the more values you have the more the error will mount.

Obvious really.

Another obvious thing is that ALL lines written to a screen are in error if they're not an odd number of pixels thick ! If they're an even number of pixels then the linee can't be 'centred' around a point (a point being a single pixel, which is the lowest common denominator for a screen or printer). How evident that is depends on the screen/printer resolution and the thickness of the line.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Jan 19, 2018 12:16 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sat Jan 20, 2018 10:08 pm    Post subject: Reply with quote

Eddie wrote:
Quote:
the SVG files created by Clearwin's new facility are written with 2 decimal places


are the values real or the truncated integer 'pixels' values then ?
I interpreted (assumed) from Paul's comment above that they were integer and only specified as real because that's the SVG spec. .

Interestingly, the details of the SVG spec. are somewhat difficult to find via google.
Not come across them yet.

I did while searching though come across by chance a plot which shows the typical effect of the 'line thickness' effect not necessarily being centred as mentioned above.

Here's a zoom of part of a plot showing how lines (gridlines in this case) can ėlook 'offset' relative to adjoining lines (Y axis tick marks in this case, because they are thicker).


You can also see that the program which created this has a bug apparently (I won't embarass the program by naming it) - look at the thicknesses of the horizontal (Y) gridlines. Those at a value of '7' are not thicker as they are at '70' and '700', and at '100' aėre thin while at '10' thick ! These anomalies show up because of the line thickness differences v the tick mark thicknesses.

Another 'false anomaly' example is here - the Y tick labels APPEAR not to be centred. In fact they are ventred, it's just that the tick marks are position 'above' the real position (I think). They are centred about the bottom of the tick marks if you like



These are just examples from another program.
We've seen similar anomalies from time to time with native%pl, which I assume are now at least partially on the road to rectification with the impending dlls release.
Of course it will tak time to iron out all the small creases, which is normal.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Sun Jan 21, 2018 12:30 pm    Post subject: Reply with quote

Quote:
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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group