Kuba,
> If you could give me a tutorial on how parameters are implemented, that'd be
> great.
> I have a vague feel for oparam and eparam, but what I don't get is exactly
> how propagation
> is supposed to work, and how can you modify the parameters. I can trivially
> parametrize,
> say, object's position -- the object then shows up with a little circle on it
> (that's the parameter
> indicator), so of course I can't move it anymore. Now how do I specify the
> value of the
> parameter?
If you understand the difference between the "eparams" (element parameters)
and the "oparams" (object parameters), then you're 90% of the way toward
understanding the whole thing.
For the element parameters, let's take your example of an element's position
(note that in xcircuit I have arbitrarily made the definitions "element" and
"object", but they are very specific, and most of the time I use the terms
correctly. In your case, you can't parameterize the position of an "object",
only the position of an "object instance", which is a type of "element".
Since I just made up all these designations 17 years ago, hopefully I am not
working against the standard etymology of computer science (if there is such
a thing)).
(1) Create a new user object, containing at least one instance of another
object, from any library/technology.
(2) Edit (descend into) the new user object. Select the instance, and use
the "A->B" toolbar button to select element parameters "X position" and
"Y position". The instance position is now parameterized. You got that
far.
(3) Pop back out to the page. Make a new instance copy of the new object.
Now, each instance has its own set of values for the (X, Y) position
of the instance inside that you parameterized the position of. If you
followed my instructions so far, then both copies have the same values
for position.
(4) Now, edit (descend into) one of the two instances. Move the parameterized
instance somewhere else. Now pop back out to the page. You should now
see that the two instances of the user object have unique values for the
position of the parameterized element inside.
Here are some observations on the method:
(1) When I descend into the user object to edit from the page, I am editing
*both* the library object *and* the instance. For anything that is not
parameterized, any change I make gets made to the object itself, and
affects every instance of that object. For anything that *is*
parameterized,
any change I make applies only to the specific instance. This is probably
a point of great confusion, and I think that it might be helpful to have
a mode (maybe default) that prevents making any changes to an instance
except those that are parameters. Either that, or have a mode in which
parameterized elements can be altered from the top level. For object
parameters, this is done with the pop-up parameter GUI window, which works
okay because there are no other pop-up windows associated with an object
instance to confuse it with, and the object parameters are all text
strings,
which work fine with a text entry widget in a GUI. You most likely
wouldn't
want to change an element position by typing the position coordinates into
a box. I *have* considered that since the "edit" ('e' key) command does
not
have any function for object instances, it could potentially be used to
edit
the position of parameterized elements inside the object without descending
into the object. But that only really works for parameterized positions,
and one would still have to descend into the object to change all the other
types of element parameters.
(2) If you select a polygon, you can parameterize the position of the element as
a whole, which is legal to do in spite of the fact that it doesn't work. I
made xcircuit crash while doing something like that just now. Looks like a
bug needs to be fixed. Technically, polygons are only able to take
position
parameters for each point, so you must be editing the polygon itself, with
the edit position on a specific point, when you parameterize it. I'm
inclined
to say that it really should be possible to parameterize the position of
the
whole polygon.
(3) The parameterization method extends beyond what has been made available from
the GUI interface. It is possible to make more than one point have the
same
parameter, so that points can track. Load the "musiclib.lps" library from
the
source lib/ subdirectory, and grab an instance of the "doublet" object.
Descend into the object and move the note on the right around. You'll see
that the bar at the top tracks with the position of the note. If you do
the
same with the "triplet" object, you'll see that the position of the center
note stays centered, and that the stem length of the center note tracks
with
the position of the bar. I haven't spent nearly enough time thinking about
a good user interface for this, although it's a quite useful feature.
Note also that it is possible to get the doublet/triplet objects screwed up
by moving or editing something that's *not* parameterized, which goes back
to the idea that one should be able to edit-lock an object, to make it
impossible to change anything in the object that is not parameterized, if
editing from a page.
(4) It is legal to parameterize an element that is on a page and not inside
a library or user object, but it is (almost) meaningless to do so.
A page is a type of object instance, but it does not make parameter
substitutions into its elements. I say it's "almost" meaningless,
because if you first parameterize and element, and then grab it and
maybe some other stuff and turn it into a user object, then you get,
well, um, . . . something. I tried it just now and I have no idea if
the result is a bug or a feature. Something else I'll have to look
into, anyway.
> I also think that somewhere along the process I'll completely get rid of
> XCircuit fonts.
> Before I do that, the big question: do local fonts print out, or are they
> merely facades?
> IOW, is it possible to make custom characters using XCircuit font files
> without having
> matching postscript fonts?
That was something else that has been on my to-do list for years and years.
Yes, I wanted to be able to convert the vector-drawn fonts into a PostScript
Type 3 (?) font and use it inside the PostScript like any other font. But
formatting the Type 3 font definition turned out to be trickier than I
expected, and as I was not able to get it done in one afternoon, I dropped
it and never got back to it. I also wanted to be able to draw out font
characters in xcircuit and turn them into a PostScript font. I got only
part way into investigating that, as well.
> Using Qt I can implement embedding *any* platform fonts as postscript
> fonts if there would be a need for it (for document portability and such).
As you know, X11 had a lousy font rendering engine. Within the last
couple of years, the fontconfig and Xft code has stabilized and is
reasonably good, but I'm sure you can well understand why 15 years
ago I opted for drawing my own fonts, making it possible to scale,
rotate, and otherwise manipulate them. I would love to have the
actual PostScript fonts printed on-screen, and would also love to be
able to use any platform font and throw it into the output file
(although I don't know how you would go about re-importing into
another platform; I assume that a Type 1 or Type 3 font embedded in
the file can be ripped out of the file and used by the font rendering
engine when the platform does not already have access to it).
---Tim
+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim) | email: [email protected] |
| Open Circuit Design, Inc. | web: http://opencircuitdesign.com |
| 22815 Timber Creek Lane | phone: (301) 528-5030 |
| Clarksburg, MD 20871-4001 | cell: (240) 401-0616 |
+--------------------------------+-------------------------------------+
_______________________________________________
Xcircuit-dev mailing list
[email protected]
http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
