Kuba,
>> Note that while playing around with this method just now, I found two
>> separate bugs, one of them a nuisance (changes the cycle after
>> parameterizing the point, without warping the cursor to that point),
>> and the other fatal (seems to be in version 3.7 only). There is also
>> a handful of annoying "features" related to the ability to modify the
>> library master object (and therefore all instances) at the same time
>> you're trying to change the parameterized point of a single instance
>> (for example, you parameterize the X-position only of a point; then
>> if you move that point in both X and Y, the change in X applies only
>> to that instance, but the change in Y applies to every instance). As
>> I mentioned before, I need to implement a "lock-out" flag that one can
>> set to prevent editing anything other than the parameterized parts of
>> an element. This seems easier said than done, though.
>
> That should be easy to do once I'm done with revamping the parameter
> system. As soon as you get a new release done, I'll merge your changes
> with my codebase.
I've been working on this for part of today, and have it working correctly
for polygons, almost working correctly for splines, and I haven't done
paths yet. I expect it will be finished sometime tomorrow. I added new
PostScript definitions "addtox" and "addtoy" that allow a parameter to be
added to an entire list of points, so that one X- or Y-value parameter
suffices for an entire polygon, spline, or path, so that it becomes a
valid procedure to select an entire polygon, path, or spline, and
parameterize the X and/or Y position of the whole element. Note that the
code in prior revisions has multiple errors in which if this procedure is
attempted, the parameter created will get a cycle value of -1, and this
will be applied as an index into the point array of the polygon or
spline, causing it to write out-of-bounds.
> As for the color-via-paremeters, I presume that we would need a way of
> specifying global default parameters? Such that the default color can be
> propagated down the tree.
It is already possible to create parameters on a page. On any page,
bring up the parameter dialog box and create a new string parameter,
then save the file. The output looks something like this:
%%Page: test 1
%%PageOrientation: Portrait
/pgsave save def bop
<</@testparam (hello) >> begin
1.0000 inchscale
2.6000 setlinewidth 752 352 translate
So it seems reasonable that one could define the default color up
front for every page:
<</p_col {0 0 0} >> begin
as a replacement for "0 0 0 scb" in the definition for "bop"
(beginning-of-page). That would be removed from the "bop" definition
to be replaced by
p_col setrgbcolor
somewhere further down in the page header (after the dictionary, of
course). Then calls to an object instance would have:
<</p_col {r g b} >>
to set a unique color for the instance, or
<</p_col p_col >>
to pass the color down the hierarchy. If you like, I can do the code
modifications to xcircuit-3.7 to implement this, and you can merge the
code changes in. I don't think it will be a huge amount of work.
However, it will change the input/output format a bit, so I would like
to have changes made to both your and my version of the code.
---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
