 |
|
|
|
|
|
|
|
|
|
|
|
C o n s t r u c t i o n s
|
|
|
|
|
|
|
|
|
|
Can only appear on straight objects or circles
(not on loci or polygon interiors,
and not on arcs as these can't be constructed at all).
No scripts, but there is one piece of advice for points on loci:
Construct a point on the path with which the locus is defined
and repeat the construction that created the driven point out of the driver point.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not supported, no replacement seems possible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not all variations are supported.
For convertable GSP sketches, you must take care not to use
the unsupported variations.
Don't do a polar translation by marking a 3-point angle
via "Transform | Mark Angle"
Two translation variants are not supported in JSP.
They would be called
"Translation/3PtAngle/{ Fixed, Marked }Distance"
(or "MarkedAngle" if the existing "MarkedAngle" versions
would use the more appropriate name "MeasuredAngle").
It is impossible to provide a script for the "FixedDistance" version
as you can't have a running script ask the user for a fixed distance!
You will have to perform this operation yourself.
One general way is to measure the angle instead of marking it,
and then translating.
If it's a point that you want to translate,
translate it by the fixed distance and a fixed angle of zero,
and then rotate the result by the marked angle.
For the "MarkedDistance" result, here is a script
which runs on any object without measuring the angle.
(In jsp.awk, macros for both fixed
and measured distances are possible.)
|
|
Translation/3PtAngle/FixedDistance
|
|
|
|
Translation/3PtAngle/MarkedDistance
|
|
|
Angle measurements are o.k. for polar translations,
but are disoriented
A suprising problem is the negative angle orientation
that is used for the other polar translations,
Translation/FixedAngle/MarkedDistance,
Translation/MarkedAngle/FixedDistance
and
Translation/MarkedAngle/MarkedDistance.
(The latter two should better be called "MeasuredAngle", not
"MarkedAngle", as mentioned before.)
Everytime you use the respective GSP constructions, your
converted object in JSP will be translated the other way!
The problem is probably due to the downward orientation
of the y axis in JSP.
It seems hard to find a workaround that works both in JSP and GSP
and doesn't rely the angle unit to be set to either radians or degrees.
But one has been found for Rotation/MeasuredAngle and can
also be used for these translations.
Unfortunately, it is impossible to replace the two constructions
that take a fixed angle or distance, as a script can't prompt for fixed values.
Find one script and a collection of two macros below.
|
|
|
Translate/MarkedAngle/MarkedDistance
|
|
|
Fixed angles and distances? No sir, but should we care?
A construction "Translation/FixedAngle/FixedDistance" is also
absent from the JSP language.
One could expect
"PolarTranslation"
to be just that, but the construction is only a synonym for "Translation".
The GSP>HTLM converter calculates the
correct x- and y-offsets while converting fixed polar GSP translations,
so there is no real need to fix this.
A jsp.awk macro could easily be done
(but keep the downward orientation of the y axis in mind).
You could just as well convert a fixed angle and distance
to the respective offsets with any calculator and then use
Translation.
To still call this construction "PolarTranslation" is a weird idea.
Of course it is a bit of a service to tell readers of converted code that
a translation was a polar one before the converter turned it into a cartesian one.
But that could be done by inserting a comment on the same line too.
Currently the "Polar" prefix is just a comment, basically.
The JSP language definitely could do with some cleaning up
(see e.g. the meaning of "Marked" in "Dilation/MarkedRatio" compared with
"Rotation/MarkedAngle"), and "PolarTranslation" is an obvious case in point.
Cartesian translations: don't mix fixed and measured offsets
If you translate by a rectangular vector, you must not enter one offset
as a fixed number and get the other offset from a measurement.
Again, I can't supply a GSP script because you can't have a script
prompt for a fixed number.
You must construct a workaround by hand.
An obvious solution, creating a constant calculation for the fixed value,
fails if you're not careful (see "Calculations" below).
I suggest using first a polar translation
with a zero angle and the measurement,
then possibly -- if the measurement is for the y distance --
a rotation by 90 degrees*,
and then a cartesian translation,
with the fixed value for one offset and zero for the other.
(* For a measured y distance,
you can't just use a polar translation with a 90 degrees angle --
see the "disoriented" section above).
|
|
|
|
|
|
|
|
Ironically, you can't convert a GSP calculation that is a constant,
i.e. a single constant number or a term using just constant numbers.
You must include some measured dummy value in the term
(and multiply it by zero, or add and then subtract it, or something)
to have the number appear in a JSP construction.
This is related to the JSP requirement that the parameter list for
the
Calculate
construction must not be empty.
|
|
|
|
|
|
|
|
|
|
Not available and not really required.
If you want the construction,
download this script and read its comments.
|
|
|
|
A c t i o n B u t t o n s
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Several buttons can be automatic, 5 in the current release.
|
|
|
|
One button per sketch can be automatic.
(You must save your sketch with just the one button selected.)
|
|
|
|
C a p t i o n s a n d F o r m a t s
|
|
|
|
|
|
|
|
|
|
|
No captions (text objects) can be created.
Explanatory text must be supplied in the HTML code surrounding the applet.
|
|
|
|
|
|
|
|
Any RGB value can be given to any objects.
Overlapping areal objects (polygons, circles) are opaque.
Objects that appear later in the construction are "bottom" (!).
The GSP>HTML converter does not handle
the four saturations of areal GSP objects.
Colours may need to be changed by hand in the converted code.
|
|
|
|
Limited palette:
black, red, magenta, blue, cyan, green, yellow.
Can be applied in four saturations to areal objects,
in just one (full) saturation to all others.
All areal objects are somewhat transparent.
|
|
|
|
|
|
The "dashed" line style is not available.
As an alternative, you can give a colour to your lines
that is close to the background colour.
This creates an optical illusion of thinness.
(If you use the GSP>HTML converter,
you must set the colour by editing the converted code.)
|
|
|
|
|
|
|
|
Can be set separately for all labels, all buttons and all measurements,
but not to single instances of these.
|
|
|
|
|
|
|
|
Mathematical format is not available,
converted measurements will show the text
known in Sketchpad as the "Text Format".
All numbers are displayed with a precision that can not be changed
and which is guessed (not too badly) by the applet,
but unfortunately restricted to 1-3 decimal digits.
Thus there is no way of displaying integers as integers,
even with the trunc/@trnc or round/@rond functions.
Trailing zeros are removed.
(Scientific notation, which is used from 10^7 to 9223372036854775
and on the same negative range, is shown with up to 15 decimal digits.
Numbers from 1e-323 to before +/-0.0005 are displayed as 0.0,
from there to before +/-0.01 with 4 decimal digits.)
Units are not displayed by default;
you have to include any units as text behind the number in GSP
(which will make it look like two units) before converting.
Lenghts and areas are measured in pixels and square pixels.
You must use calculations if you want to scale to any other unit.
|
|
|
|
|
|
E m b e d d e d O b j e c t s
|
|
|
|
|
|
|
|
| |
|
Images in GIF format,
must be given via an absolute URL.
Both the applet and the picture must come from an HTTP server.
|
|
|
|
System dependent and not portable between the Mac and Windows platforms.
|
|