[PythonCAD] pythoncad drawing

[Art Haas]

On Tue, Jul 27, 2004 at 12:30:31AM -0500, Eric Wilhelm wrote:
> 
> 1.  Text (particularly scaling and rotating) is problematic in every gui 
> toolkit I have ever seen (though I haven't tried coding it in Qt or Wx.)  I 
> believe this is why autocad has that ugly stroked font as its default.  My 
> guess is that most of the high-end cad programs are using vectorizations of 
> the text for their on-screen representation.  How does the Gimp handle this 
> with Gtk?

QT has a global transformation matrix which you can modify to handle
things like scaling and rotation. GTK doesn't have this, but GNOME
apparently does via the libart library (I think).

> I see an 'angle=' property in the TextLine element, which apparently is not 
> implemented yet (maybe when the rotation transform is available?)

Yes. I added the 'angle' attribute for the ability to have the text at
some angle, but there is no code doing this right now.

> Text height apparently must be an integer?  This has got to somehow turn into 
> a float.

Text handling in PythonCAD has stayed just one step beyond primitive.
When I added it initially I thought that the text size should be defined
in points, but that approach is wrong. The text size will need to be
defined as a float, and the text size (as points) scaled to fit the
value.

> 
> 2.  Arc angles (and presumably angle properties which are not yet utilized 
> (e.g. for text)) are stored in degrees.  This may or may not become 
> problematic as you convert back and forth from degrees to radians in 
> trigonometric calculations.  Aside from that, it is just somewhat irregular 
> to me, so it is possibly a matter of convention-conflict.  Can anyone cite 
> examples of other file-formats which support degree angles?  What about both 
> degree and radian angles?  Is it possible to specify that the angle is in 
> degrees in the .xsd?

I thought specifying the angles in degrees was easier to deal with than
keeping them as radians, and I still believe this to be true. There is
the extra step of converting them to radians when doing trig operations,
but that is a small price to pay. 

> 3.  Points are not allowed to be proper entities in this scheme (maybe a 
> "Mark" entity would be able to have linetype, color, etc.)
 
I've always viewed points as just infinitely small entities, so
assigning them colors or linetypes doesn't make sense. The program could
be adjusted to draw points as 1 or 2 pixel boxes on the screen, and if
that were done I'd suggest adding an option in the preferences for
setting the display color.

> 4.  I find the point-table concept somewhat  objectionable.  Unless you are 
> aiming for relational drafting, it seems somewhat overkill.
 
???

> 5.  I'd like to see a transparent value available for the
> INACTIVE_LAYER_COLOR value which would leave the inactive layer
> entities painted in their actual colors, but that may be more of
> an interface issue.

This behavior of changing the entity colors comes from my experience
with ME-10. I thought it was a good way of indicating that the entities
are not in the current active layer. ME-10 also had a mode where the
inactive layer entities were kept in their normal color, and I always
found that confusing when I tried to identify which on screen entities 
I could modify and which ones I couldn't.

Art
-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822