SVG & SuperCard

Using SuperCard and the Runtime Editor... working with windows, backgrounds, cards and menus.

SVG & SuperCard

Postby DougDenby » Mon Nov 27, 2017 8:43 am

SVG & SuperCard Vector Lines

Recently I have been exploring converting graphic images created in SuperCard using the vector tool (all graphic tools other than bitmaps) to SVG to display the images in browsers. On the surface this should be fairly easy as they are all drawn on a grid starting in the topLeft and proceeding to the bottom right. But it isn’t that easy.

SuperCard follows the graphic system created by Apple back in the late 1970’s and perfected for the Lisa and Macintosh. This system uses a grid based on lines between pixels. SVG uses a similar grid, but based on the pixels.

So what! Well, logically a line drawn horizontally across the screen has no height. But if that were so then it would not be visible, but it is. In SuperCard, the minimum height of a line is 1 and shows up as penHeight and the minimum width is also 1 (penWidth). This makes it visible on the screen, unless the visibility is set to false. So, each pixel is a square 1 by 1. A penWidth of 2 and a penWidth of 10 makes a dot into a square 2 x 10. What happens is that as the penWidth is increased each pixel in the line is expanded to the right by the appropriate number. The result is that a line with a penWidth of 10 actually extends 10 pixels beyond the actual end of the line. The same is true for vertical dimensions, going down.

In SVG, this is not true. A line (called a stroke in SVG) has only a stroke-width. As the width of the line is increased, pixels are added to either side of the line. This is much more logical. The end of the line (stroke-linecap) can be drawn in three styles: butt, round, or square. The butt version stops it exactly at the end of the line. The round version draws a circle with radius equal to one half of the stroke-width with centre exactly at the end of the line, thus extends beyond the end of the line, but with a nice round end. The stroke-linecap:square draws a square at the end, with sides equal to the stroke-width. While you might think that would look like a SuperCard line, it does not. The sides of the square are parallel to the slope of the line itself, not horizontal and vertical as in SuperCard.

For close graphics like a rectangle, SuperCard adjusts the location of the lines so that the outside edges of the lines are exactly at the outside edges of the defined rectangle. SVG makes no such adjustment. So a rectangle with a width of 20 and height of 20 with a penHeight of 5 and a penHeight of 5 in SuperCard actually has the lines drawn inside the rectangle. In SVG that is not true, the center of lines are lined up with the dimensions of the rectangle and so the rectangle width stroke-width:5 is actually 25 pixels high and 25 pixels wide.

This differences make for some interesting code in my conversion script.

Doug
P.S. Some of my terms may not be accurate, but the tale is.
DougDenby
 
Posts: 56
Joined: Mon Jul 07, 2008 3:28 am

Re: SVG & SuperCard

Postby LorenzT » Tue Nov 28, 2017 2:48 am

Hi Doug
Is your goal to produce high resolution graphs?
Some time ago I made a project that translates SC objects into CoreGraphic objects within SC with the help of an external
You can find the grc2coreGrc-Showcase here: viewtopic.php?f=39&t=1249

Lorenz
LorenzT
 
Posts: 176
Joined: Thu Dec 02, 2010 2:32 am
Location: Switzerland

Re: SVG & SuperCard

Postby DougDenby » Wed Nov 29, 2017 8:17 am

Hi Lorenz,

No, my goal is to convert the SuperCard Vector Graphics to SVG graphics so they can be embedded into any HTML document to be displayed on any computer over the internet.

I like to draw things like wiring diagrams for my rather unique motorhome. The Supercard vector system works very well, especially when working with ModuloPi. Wires can be reshaped at will. The only major problem I have doing this is displaying multiple colored wires. Once completed, I can easily convert the card image to a graphic image, for distribution. These images are JPEG or some other bitmap, which have the inherent problems of bit maps. SVG graphics in HTML are quickly and easily drawn, take up less space, and can be added easily to any HTML file.

Thanks for the idea with CoreGraphics, but that is a whole new area of learning for me.

At this point, I have created a script that handles all the conversions except groups. I will tackle that over the next couple of days. I have a few ideas that will make it work. A big problem was arcs, but I got it figured out, and without having to resort to any complex mathematics, sin or cos functions. In another post, I will show how I did it. So far I have not had to resort to extensions or xFunctions or anything like that. Just plain old SuperCard language.
DougDenby
 
Posts: 56
Joined: Mon Jul 07, 2008 3:28 am

SVG arcs

Postby DougDenby » Wed Nov 29, 2017 10:18 am

Converting Supercard Arcs to SVG Arcs was an exercise.

Elliptical Arc Problem

Context:
Arc is a pie shaped graphic;
Grid pattern is right and down, measured in pixels;
Angles measured clockwise in degrees (0 is vertical up from the center of ellipse);
Speed of calculation is important;
Trig functions acceptable (cos, sin, etc.).

Given:
Ellipse is oriented square to the grid (i.e. the radii form a square angle on the grid);
StartAngle (measured clockwise, always positive, in degrees);
ArcAngle (number of degrees of sweep, always clockwise, always positive, in degrees);
Left, right, top and bottom of surrounding rectangle (which always includes the center).

Output Needed, using the same grid:
Co-ordinates (cX,cY) of center of ellipse;
Radii (rX,rY) of ellipse;
Co-ordinates (sX,sY) of starting point of arc;
Co-ordinates (eX,eY) of ending point of arc;
Large-arc-flag (boolean representing whether arc is equal to or greater than 180°, or less than 180°);
Sweep-flag (boolean representing whether arc is drawn clockwise or counterclockwise from starting co-ordinates).

While I conquered these problems, I ran into another issue: When SuperCard fills an arc, it does so by creating a pie shaped outline by joining each of the ends of the arc with the ellipse center. SVG does not do this. SVG fills an arc by drawing a single straight line joining each end of the arc.
DougDenby
 
Posts: 56
Joined: Mon Jul 07, 2008 3:28 am

Re: SVG & SuperCard

Postby vinnie-bob » Wed Nov 29, 2017 5:08 pm

Save templates of wiring diagrams, export to SVG. no fuss, no muss:

https://www.omnigroup.com/omnigraffle/new/
------
vince
------
User avatar
vinnie-bob
 
Posts: 216
Joined: Sun Jul 06, 2008 10:55 am
Location: Des Moines, Iowa, USA

Re: SVG & SuperCard

Postby DougDenby » Thu Nov 30, 2017 7:51 am

Omnigraffle is new to me. I took a look at its free test and may investigate further. It requires a lot of learning by me but what the heck. It also requires some more dollars, but again, what the heck.

One problem is that I have to literally re-draw each existing diagram, from scratch. Another problem is that all Omnigraffle does is draw (it looks to do that very well), whereas SuperCard does an awful lot more.

A concern for me is longevity. I have been using SuperCard from the very beginning, when it competed with hypercard, a free and wonderful tool in its own right. SuperCard lasted. Hypercard did not. So many products have come and gone. SuperCard is still here, and still relevant, growing with the Mac. My writing this SVG tool can only enhance SuperCard's functioning for me.
DougDenby
 
Posts: 56
Joined: Mon Jul 07, 2008 3:28 am

Re: SVG & SuperCard

Postby codegreen » Thu Nov 30, 2017 8:48 am

Actually QuickDraw itself (not SC) is responsible for the vicissitudes of where pixels sit relative to the coordinate system for lines and polygons vs rects and ellipses.

FWIW I went through this whole mess TWICE this year (first adding marquees for resizing antialiased objects, then again porting the spot rendering code to Cocoa) so FWIW you have my sympathy...

;)
-Mark
codegreen
 
Posts: 1503
Joined: Mon Jul 14, 2008 11:03 pm

Re: SVG & SuperCard

Postby DougDenby » Fri Dec 01, 2017 7:52 am

Hi Mark,

I am aware that QuickDraw is the culprit, although I did not name it, I did describe it in my first post. As I understand, it QuickDraw is officially deprecated, as of MacOSX v.10.4 or 10.5. Also I understand that the Apple's official stance is that modern applications should be using Quartz graphics. So, question. has the SuperCard team developed a new Quartz graphics based vector drawing system for the about to be released new version of SuperCard?
DougDenby
 
Posts: 56
Joined: Mon Jul 07, 2008 3:28 am

Re: SVG & SuperCard

Postby codegreen » Fri Dec 01, 2017 5:35 pm

I figured you knew it was QD, I just thought the audience might not.

That's a really long, complicated story. Basically Apple could have made that QD->Quartz transition vastly easier if they'd only provided a public API as a migration path for polygons, which I literally begged them to do for years.

However sadly the person in charge of that decision was a complete idiot, and though he fancied himself a programmer was too dull-witted to even begin to comprehend how deep and dark that code would be to write - especially since it would have to EXACTLY mimic code Apple ALREADY WROTE to draw antialiased polygons in PICTs, but refused to make publicly accessible. In the words of one of the fathers of QD whom I once cornered to ask advice about it: "You do NOT VANT to write zis code! I vould not write zis code myself, and I invented polygons!"

So instead in 4.8 QD primitives are antialiased by a devious and roundabout method that tricks Apple's own code into doing it anyway, and Quartz is used directly only for the tool marquees and such.

That rendering code has since ALMOST all been ported to Cocoa, but a release that uses it won't be available until sometime probably late next year (assuming this one doesn't finish me off first... ;-) ).

-Mark
codegreen
 
Posts: 1503
Joined: Mon Jul 14, 2008 11:03 pm

Re: SVG & SuperCard

Postby DougDenby » Sat Dec 02, 2017 8:46 am

Thanks for the detailed response Mark.

Now I know that my little project will not be in vain. It's almost complete, to the level that I need it. Since, my intent is not to duplicate all SuperCard displays, but only those vector based images that I produce, the project will handle only check box buttons at this point. When I get to trying to figure out how to convert SuperTalk routines to Javascript and attach that to specific buttons, I will figure out how to convert the other button types. But not now.

Text has been an interesting experience. Both SuperCard and SVG use the same basic font display routines, but as SuperCard runs only on Macintosh computers, whereas SVG runs in virtually all modern browsers on all modern OS's and all modern platforms, the fonts used need to be limited. Otherwise displays look really odd, although they will render.

Because of this reality, I have created a restricted Font menu for my purposes. On that menu I have web fonts that are commonly used: Arial, Courier,Times (Times New Roman); Ones that normally work: Avant Garde, Bookman, Garamond, Palatino; and fonts common to both MacOS and Windows: Arial Black, Comic Sans MS, Georgi, Impact, Trebuchet, Verdana. But all of these are in constant flux, and I don't like many of them.
DougDenby
 
Posts: 56
Joined: Mon Jul 07, 2008 3:28 am

Re: SVG & SuperCard

Postby DougDenby » Mon Dec 11, 2017 7:03 am

SVG & Color & SuperCard

SuperCard presents a 16 by 16 array of colors for selection. That is 256 potential colors. However, there are far more than that available on modern monitors. Well over 16,000 discrete colors can be generated using the RGB system of 2 digit Hex values: FF FF FF is white, 00 00 00 is black. I am old enough to have worked on computers with a maximum of 4 colors, so I know that things change, often for the good.

The SuperCard array uses the RGB system. The first 200 or so colors are generated with a simple triple loop.

put empty into tTable
put 256 into tBlue
put 256 into tGreen
put 256 into tRed
put 51 into tStep
repeat while tRed > 0
repeat while tGreen > 0
repeat while tBlue > 0
put tRed & tGreen & tBlue into tColor
put tColor into item i of tTable
add 1 to i
subtract tStep from tBlue
end repeat
subtract tStep from tGreen
end repeat
subtract tStep from tRed
end repeat

After that similar loops using 34 and 17 as steps are employed. An attempt was made to ensure no duplicate colors, but there are a couple. While all that is very nice, humans use names for colours and SVG, being a part of HTML uses names as well. But which names? Yes, there are standards, but who created them?, and did everybody else adopt the same standards? Answer: It is a mess. It is a result of attempts by corporations to create a loyal base of fans for a specific brand. Add to this the fact the each human sees a slightly different color. Try getting into a conversation between genders about the proper name for a specific color.

When the SuperCard color palette is laid next to the most common color name charts of web colors, only a handful of colors match. My color needs are limited, mainly to the colors of the plastic covering copper wires. These colors are augmented often with stripes. SuperCard can not produce a color striped line. Neither can SVG.

SuperCard can, via the PenPattern produce some rather odd two colour lines, depending on the pattern. But the pattern is limited to an 8 by 8 stamp. The printing industry for years was able to create all sorts of variant greys and colous for years using a very limited palette by utilizing various patterns of alternately colored pixels. Supercard evolved on hardware that started with only two colors: black and white. The use of these patterns allowed increasing the visual experience. Penfore and PenBack colors are placed on the black and white dots of the 8 by 8 matrix.

SVG can produce a variety of dotted and dashed lines, but each of only a single color. But the length of the dash can be adjusted. This allows one to overlay one line upon the other to created a double colored line consisting of alternately colored dashes.

It makes for some interesting solutions to the conversion. My answer, in SuperCard, has been to define a specific subset of colors on a special palette and to place color names on the colors. I also use only 2 patterns: one for solid colored wires and one for striped colors. When the translation to SVG occurs, one of the patterns becomes dashed lines.
DougDenby
 
Posts: 56
Joined: Mon Jul 07, 2008 3:28 am


Return to SuperCard Basics

Who is online

Users browsing this forum: No registered users and 1 guest

cron