Mail Archives: geda-user/2017/07/19/22:55:26
Hello Bert,
On Wed, 19 Jul 2017, Bert Timmerman (bert DOT timmerman AT xs4all DOT nl) [via geda-user AT delorie DOT com] wrote:
> Erich Heinzle (a1039181 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
>> During development of the Protel Autotrax/Easytrax import/export
>> plugin, a method for exporting complex polygons to the Protel
>> Autotrax/Easytrax format was needed, given its limited support for
>> polygons other than solid rectangular fills.
>>
>> A PolyHatch() function was implemented in a separate plugin, which can
>> now be used to convert any selected polygon on a layout with user
>> defined cross hatching spacing, the option of vertical and/or
>> horizontal cross hatching, and the option of clearance.
>>
>> This plugin is now included in svn head by default, and will be in the
>> next release of pcb-rnd.
>>
>> It can be invoked with :PolyHatch(interactive) after selecting a
>> polygon or polygons.
>>
>> For further details and screenshots, see:
>>
>> http://vk5hse.blogspot.com.au/2017/07/polyhatch-command-for-cross-hatching.html
>>
> Hi,
>
> Good job ;-)
>
> http://www.sandpiper-inc.com/stipple/html/ comes to mind.
Thanks, we do know about that plugin. Before sitting down to implement our
own, I considered whether we could just use an existing implementation. I
concluded it would be magnitudes more expensive to reuse that plugin than
to write the necessary code from scratch.
There are a few problems that made us unable to use that plugin as-is:
1. it is written in C++ while pcb-rnd has a strict C89 policy (which is
very benefical for both developers and users so we are not going to give
it up)
2. it even depends on boost while we are trying to remove such mega-lib
dependencies
3. it is pretty much coupled to gtk; that means even the autotrax exporter
would indirectly start to depend on gtk. We absolutely want to avoid such
hardwired dependencies and want to keep things modular and want to keep
gtk optional.
It would have taken a major rewrite to get that plugin into pcb-rnd. I
remember this topic popped up when I imported the rest of the well known
pcb plugins. I think I even communicated with the original author. My
conclusion was it would require a full rewrite to include it in pcb-rnd
and nobody felt like doing that.
While our implementation is probably less capable on the extras, it does
solve the problem we wanted to solve, it is written in C89 and has 0
dependencies. It costed less than 500 sloc and about 13 hours to develop
and test. So it was way cheaper to "reinvent the wheel" than trying to
reuse the existing one that doesn't fit.
Regards,
Igor2
- Raw text -