Re: gEDA-user: Schematic Capture to dxf File - using gEDA, Inkscape, and pstoedit

[Alberto Maccioni]

Hello,
some time ago I posted some code to add an export gui that produces
directly a cnc G-CODE file.
Maybe you want to try that also.

Best regards,
Alberto


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Schematic Capture to dxf File - using gEDA, Inkscape, and pstoedit

[Bert Timmerman]

Hi Dave, 

> -Original Message-
> From: geda-user-boun...@moria.seul.org 
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of d...@umich.edu
> Sent: Wednesday, January 27, 2010 11:35 PM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: Schematic Capture to dxf File - using 
> gEDA, Inkscape, and pstoedit
> 
> Bert Timmerman wrote:
> > Hi Dave N6NZ, d...@umich.edu,
> > 
> > 
> > FWIW, There lives a dxf exporter for pcb in a not yet 
> finished state at:
> > 
> > http://github.com/bert/pcb-dxf-hid
> > 
> > Maybe something to look at for you guys.
> > 
> > I have ample time for further development on this exporter in the 
> > foreseeable future, so you may clone/fork as yo see fit.
> > 
> > Kind regards,
> > 
> > Bert Timmerman. 
> 
> That is good news! From what file format are you starting the 
> conversion? If you start with gerber, other pcb CAD programs 
> could use it.
> 
> Thanks,
> Dave
> 
> 

It's a pcb exporter, so after compiling it becomes part of the pcb app and
it gets data from the pcb internal data structs.

Not suitable for gerber files, peoples using other pcb-warez (eagle,
fritzing, ..., and-what-not) need to adapt it to these specific internal
data structures.

One caveat might be that the pcb-dxf-hid code may have some bit rot as pcb
hid structs seem to have changed a little bit over time.

Kind regards,

Bert Timmerman.



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Parts Manager Working Document

[Bob Paddock]

> Rather than having a component "class", explicitly subclassed in the
> database to contain resistor specific attributes, I would do it similar
> to the following:
>
> 1 "component class" / table, one size fits all. Each has a component ID.

The Component ID is what I list on BOM.

> 1 "attribute type class" / table, one size fits all (?)
>
> An entry might be:
>
> Attr_id            213

... Seems to me like we are starting (re)invent an ERP system.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Parts Manager Working Document

[Peter Clifton]

On Wed, 2010-01-27 at 15:18 -0800, Edward Hennessy wrote:
> --- On Wed, 1/27/10, Peter Clifton  wrote:
>  
> > Good database design dictates that the device types are not
> > hard-coded
> > into the data-structure, there is no explicit "resistors"
> > table JOIN'd
> > to drag in resistor specific data etc..
> 
> There really isn't a good solution for relational databases.
> This article summarizes the trade-offs well:
> 
> http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/

I was more thinking along these lines..

Rather than having a component "class", explicitly subclassed in the
database to contain resistor specific attributes, I would do it similar
to the following:

1 "component class" / table, one size fits all. Each has a component ID.
1 "attribute type class" / table, one size fits all (?)

An entry might be:

Attr_id213
Attr_name  "tolerance"
Attr_legal_values  percentage

Attr_id214
Attr_name  "stock_level"
Attr_legal_values  integer



And there would be some table which mapped components and their
attributes.

Component_id   123123123
Component_name "foo" <-- Ok, this could be a mandatory 
attribute, but that is getting crazy!

And the mapping:

Component_id   123123123
Attr_id213
Attr_value 0.1%

Component_id   123123123
Attr_id214
Attr_value 100



In this respect, you're using the database as a kind of "meta-database",
where the real mapping between objects and their attributes exists
within a limited number of tables.

OTOH, someone can probably tell me why this is "BAD^(TM)", and how
modern databases can support ad-hock addition of specialised tables
and / or fields to the existing database structure.

One could also envisage tables with guides to creating component
classes.

Component_class_id1
Component_class_name  "Generic physical component"
Component_class_parent_id NULL


Component_class_id37
Component_class_name  "Resistor"
Component_class_parent_id 1

Component_class_id 1
Component_class_attr_id214
Component_class_attr_rule  "Optional"
...
Component_class_id 37
Component_class_attr_id213
Component_class_attr_rule  "Mandatory"



Anyway.. I should be working.. and I'm not. Back to it!

Best wishes,

Peter C.



> PostgreSQL operates as both a relational and object database,
> so an implementation in PostgreSQL would be much cleaner.
> 
> I believe the options include a single table for part, or
> using multiple tables for part. There are advantages and
> disadvantages for either.  From previous experience, I'm 
> in the multi-table camp.  The mailing lists seem to be
> gravitating to the single table implementation for reasons
> of simplicity.
> 
> I'd like to point out that the database implementation uses
> views to provide logical data independence. So, the user
> and applications would be relatively immune to the underlying
> database structure.  So, supporting both single and multiple
> tables at the user's option could be done also.
> 
> The git repository contains some of the SQL code to get the
> multi-table database up and running.  The sample code
> probably describes the database structure better than my 
> working document.
> 
> Cheers,
> Ed
> 
> 
> 
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Parts Manager Working Document

[Edward Hennessy]

--- On Wed, 1/27/10, Peter Clifton  wrote:
 
> Good database design dictates that the device types are not
> hard-coded
> into the data-structure, there is no explicit "resistors"
> table JOIN'd
> to drag in resistor specific data etc..

There really isn't a good solution for relational databases.
This article summarizes the trade-offs well:

http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/

PostgreSQL operates as both a relational and object database,
so an implementation in PostgreSQL would be much cleaner.

I believe the options include a single table for part, or
using multiple tables for part. There are advantages and
disadvantages for either.  From previous experience, I'm 
in the multi-table camp.  The mailing lists seem to be
gravitating to the single table implementation for reasons
of simplicity.

I'd like to point out that the database implementation uses
views to provide logical data independence. So, the user
and applications would be relatively immune to the underlying
database structure.  So, supporting both single and multiple
tables at the user's option could be done also.

The git repository contains some of the SQL code to get the
multi-table database up and running.  The sample code
probably describes the database structure better than my 
working document.

Cheers,
Ed



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gschem font scaling

[Stefan Salewski]

On Wed, 2010-01-27 at 14:05 +, Peter Clifton wrote:
> 
> It does mean that postscript output has seen its font size increase (by
> a factor of x1.3). Sometimes I still think I made the wrong decision in
> doing it that way.
> 
> The choice was either smaller on-screen fonts compared to pre gEDA
> 1.6.0, or try to match on-screen - and increase the postscript output
> size.
> 
> I really wish I'd fixed 1-1, and just shrunk the on-screen rendering
> now. Unfortunately, this isn't something we can easily change back - as
> consistency is good.
> 
> Technically, it "could" go in a 1.6.1 update - but I suspect there would
> be a lot of (valid) opposition to that, since it isn't really a "bug
> fix" per-se.
> 

Indeed my feeling is that preserving the font size for print out would
have been the better decision.

gschem prior to 1.6 was not fully "What You See Is What You Get". I
think for such a case most people optimize the schematics to get a fine
looking printout. At least this is what I did. I used default font size
for screen and printout, and moved symbols close together on screen so
that text sometimes touches the symbols. I carefully set the reference
point for all text, so the postscript output with scaled down text looks
nice. I made a printout with 1.6 -- does not look nice.

But of course this is not a serious problem, at least not for me.

Best regards

Stefan Salewski




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Schematic Capture to dxf File - using gEDA, Inkscape, and pstoedit

[dfro]

Bert Timmerman wrote:

Hi Dave N6NZ, d...@umich.edu,


FWIW, There lives a dxf exporter for pcb in a not yet finished state at:

http://github.com/bert/pcb-dxf-hid

Maybe something to look at for you guys.

I have ample time for further development on this exporter in the
foreseeable future, so you may clone/fork as yo see fit.

Kind regards,

Bert Timmerman. 


That is good news! From what file format are you starting the 
conversion? If you start with gerber, other pcb CAD programs could use it.


Thanks,
Dave


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gschem font scaling

[Peter Clifton]

On Wed, 2010-01-27 at 20:36 +0200, Duncan Drennan wrote:
> > Recompile, sorry. See libgeda/src/o_text_basic.c
> >
> > Search:
> >
> > #define GEDA_FONT_FACTOR 1.3
> >
> > You probably want it "1.0"
> 
> Thanks, I'll give it a try with minipack sometime soon. Is there (or
> is there supposed to be) any correlation between the gschem text size
> and the actual printed size? e.g. is text size = 10 supposed to render
> 10pt text when printed?

10 "gEDA font units" multiplies with the GEDA_FONT_FACTOR to give a size
in points.

That is supposed to match the size of the font in the gEDA world - as
scaled by the paper sizes. Whilst there is no official definition of the
units - you will find that the title symbols for various paper sizes
match up if you interpret the coordinates as mils, 1/1000th of an inch.

Now, in order to achieve a sensible amount of content on the page,
people typically use something like an A2 (or larger) title-block, even
when printing on A4 paper. That means that a 13pt font size (10 gEDA
units in the stock build), will render much smaller than a 13pt font
emitted from your word processor.

(IE.. It all depends on the print options, and title-block you use).

> Thanks for making the builds available. Could you please send me the
> nsi installer script? I would like to figure out how that works so
> that I can package an unofficial build.

Attached (for everyone's benefit, and for archival)
/**
 *  EnvVarUpdate.nsh
 *: Environmental Variables: append, prepend, and remove entries
 *
 * WARNING: If you use StrFunc.nsh header then include it before this file
 *  with all required definitions. This is to avoid conflicts
 *
 *  Usage:
 *${EnvVarUpdate} "ResultVar" "EnvVarName" "Action" "RegLoc" "PathString"
 *
 *  Credits:
 *  Version 1.0 
 *  * Cal Turney (turnec2)
 *  * Amir Szekely (KiCHiK) and e-circ for developing the forerunners of this
 *function: AddToPath, un.RemoveFromPath, AddToEnvVar, un.RemoveFromEnvVar,
 *WriteEnvStr, and un.DeleteEnvStr
 *  * Diego Pedroso (deguix) for StrTok
 *  * Kevin English (kenglish_hi) for StrContains
 *  * Hendri Adriaens (Smile2Me), Diego Pedroso (deguix), and Dan Fuhry  
 *(dandaman32) for StrReplace
 *
 *  Version 1.1 (compatibility with StrFunc.nsh)
 *  * techtonik
 *
 *  http://nsis.sourceforge.net/Environmental_Variables:_append%2C_prepend%2C_and_remove_entries
 *
 */


!ifndef ENVVARUPDATE_FUNCTION
!define ENVVARUPDATE_FUNCTION
!verbose push
!verbose 3
!include "LogicLib.nsh"
!include "WinMessages.NSH"
!include "StrFunc.nsh"

;  Fix for conflict if StrFunc.nsh is already includes in main file ---
!macro _IncludeStrFunction StrFuncName
  !ifndef ${StrFuncName}_INCLUDED
${${StrFuncName}}
  !endif
  !ifndef Un${StrFuncName}_INCLUDED
${Un${StrFuncName}}
  !endif
  !define un.${StrFuncName} "${Un${StrFuncName}}"
!macroend

!insertmacro _IncludeStrFunction StrTok
!insertmacro _IncludeStrFunction StrStr
!insertmacro _IncludeStrFunction StrRep

; -- Macro Definitions 
!macro _EnvVarUpdateConstructor ResultVar EnvVarName Action Regloc PathString
  Push "${EnvVarName}"
  Push "${Action}"
  Push "${RegLoc}"
  Push "${PathString}"
Call EnvVarUpdate
  Pop "${ResultVar}"
!macroend
!define EnvVarUpdate '!insertmacro "_EnvVarUpdateConstructor"'
 
!macro _unEnvVarUpdateConstructor ResultVar EnvVarName Action Regloc PathString
  Push "${EnvVarName}"
  Push "${Action}"
  Push "${RegLoc}"
  Push "${PathString}"
Call un.EnvVarUpdate
  Pop "${ResultVar}"
!macroend
!define un.EnvVarUpdate '!insertmacro "_unEnvVarUpdateConstructor"'
; -- Macro Definitions end-
 
;--- EnvVarUpdate start
!define hklm_all_users 'HKLM "SYSTEM\CurrentControlSet\Control\Session Manager\Environment"'
!define hkcu_current_user  'HKCU "Environment"'
 
!macro EnvVarUpdate UN
 
Function ${UN}EnvVarUpdate
 
  Push $0
  Exch 4
  Exch $1
  Exch 3
  Exch $2
  Exch 2
  Exch $3
  Exch
  Exch $4
  Push $5
  Push $6
  Push $7
  Push $8
  Push $9
  Push $R0
 
  /* After this point:
  -
 $0 = ResultVar (returned)
 $1 = EnvVarName(input)
 $2 = Action(input)
 $3 = RegLoc(input)
 $4 = PathString(input)
 $5 = Orig EnvVar   (read from registry)
 $6 = Len of $0 (temp)
 $7 = tempstr1  (temp)
 $8 = Entry counter (temp)
 $9 = tempstr2  (temp)
 $R0 = tempChar (temp)  */
 
  ; Step 1:  Read contents of EnvVarName from RegLoc
  ;
  ; Check for empty EnvVarName
  ${If} $1 == ""
SetErrors
DetailPrint "ERROR: EnvVarName is blank"
Goto EnvVarUpdate_Restore_Vars
  ${EndIf}
 
  ; Check for valid Action
  ${If}$2 != "A"
  ${AndIf} $2 != "P"
  ${AndIf} $2 != "R"
SetErrors
DetailPrint "ERROR: Invalid Action - 

Re: gEDA-user: gsch2pcb question

[DJ Delorie]

This usually means you need a gafrc that points at a local symbol
repository.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: gsch2pcb question

[vinny]

Hello,
I have a board layout using geda system, schematic and pcb. this project
was put aside for while, during this time I update fedora and also geda
files, but I saved the home directory. Now I made some small
modification on schematic and then try to execute gsch2pcb again, the
old layout got stripped of most of the parts and the T14511.new.pcb file
has very few parts. I was not able to trace the source of problem the
schematic find all the .sym files and yet most of the warning are about
the .sym files. I also removed the m4 directory from /usr/share/pcb, no
difference. Hope some of you can help, thank you in advance. Vinny
 Here is the gsch2pcb complaint. 

[vi...@localhost t14511]$ gsch2pcb project
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [LP24-500.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [Buz-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [89C51R2X.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [respacvert9-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [OAC-5-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap_pol-2.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap_pol-2.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap_pol-2.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [switch-sp3t-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [resistor-3.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [LED4-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [ULN2004-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [rpack7-2.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [DIGY_SW4-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [LP24-500.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [Buz-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [89C51R2X.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [respacvert9-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [OAC-5-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap_pol-2.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap_pol-2.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap_pol-2.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [switch-sp3t-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [cap-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [resistor-3.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [LED4-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [ULN2004-1.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [rpack7-2.sym]
WARNING: Found a placeholder/missing component, are you missing a symbol
file? [DIGY_S

Re: gEDA-user: gschem font scaling

[Duncan Drennan]

> Recompile, sorry. See libgeda/src/o_text_basic.c
>
> Search:
>
> #define GEDA_FONT_FACTOR 1.3
>
> You probably want it "1.0"

Thanks, I'll give it a try with minipack sometime soon. Is there (or
is there supposed to be) any correlation between the gschem text size
and the actual printed size? e.g. is text size = 10 supposed to render
10pt text when printed?

> One thing I'm absolutely against is introducing separate on-screen, and
> output scalings. gschem is WYSIWYG, and something I think we want to
> keep.

Definitely agree on that.

> I'm not violently opposed to adding a setting for the scaling factor -
> but I'd really prefer it wasn't necessary.

Building with minipack is fairly straightforward (once you've done it
once...). I'm quite happy to sort my particular problem out that way.

>> FYI I am working with the win32 builds.
>
> Ok, cool - glad to hear they are working for you.
>

They've been working well for me since you first released an
unofficial build. I use the mingw tools along with them (mainly make)
for automating some of the tasks. I think I raised the issues I had
way back when you first offered a build - since then, pretty smooth
sailing. I've grabbed your Cairo build and installed it earlier today
(schematic time again) so I'll let you know if I see anything
suspicious. I generally output directly to a pdf though, so printing
has never really been an issue to me.

Thanks for making the builds available. Could you please send me the
nsi installer script? I would like to figure out how that works so
that I can package an unofficial build.

Thanks,
Duncan

-- 
Turn ideas into products - http://www.engineersimplicity.com
The Art of Engineering - http://blog.engineersimplicity.com


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gschem postscript bug

[Peter Clifton]

On Wed, 2010-01-27 at 18:20 +, Peter Clifton wrote:

> Could you try applying the attached patch please. I think it is right,
> but I've not actually tried it myself - I'm chasing another work task
> which is keeping me busy!

More haste, less speed... try this one (now with content!)
>From 012a3c3ddf55b0260b296476fa7d047af88818f7 Mon Sep 17 00:00:00 2001
From: Peter Clifton 
Date: Wed, 27 Jan 2010 18:17:45 +
Subject: [PATCH] libgeda: Fix postscript output issue with certain paths

Ensure we always have a space before the "stroke" command.

Reported-by: Donald Tillman 
---
 libgeda/src/o_path_basic.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libgeda/src/o_path_basic.c b/libgeda/src/o_path_basic.c
index 991d6cc..3d8c40d 100644
--- a/libgeda/src/o_path_basic.c
+++ b/libgeda/src/o_path_basic.c
@@ -610,7 +610,7 @@ static void o_path_print_solid (TOPLEVEL *toplevel, FILE *fp, PATH *path,
 
 switch (section->code) {
   case PATH_MOVETO:
-fprintf (fp, "closepath ");
+fprintf (fp, "closepath");
 /* Fall through */
   case PATH_MOVETO_OPEN:
 fprintf (fp, "%i %i moveto",
@@ -627,12 +627,12 @@ static void o_path_print_solid (TOPLEVEL *toplevel, FILE *fp, PATH *path,
  section->x3 - origin_x, section->y3 - origin_y);
 break;
   case PATH_END:
-fprintf (fp, "closepath ");
+fprintf (fp, "closepath");
 break;
 }
   }
 
-  fprintf (fp, "stroke\n");
+  fprintf (fp, " stroke\n");
 }
 
 
-- 
1.6.5



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gschem postscript bug

[Peter Clifton]

On Wed, 2010-01-27 at 08:32 -0800, Donald Tillman wrote:
> Hey folks,
> 
> In gschem 1.6.0.20091004, I use the File menu to create a postscript
> file for my schematic.  But I can't print or view the file; there's a
> postscript syntax error.
> 
> The problem is that "lineto stroke" is written out as "linetostroke"
> in the .ps file.
> 
> Example here:
> 
> 
> 10 setlinewidth
> 40800 48000 moveto 40833 48045 lineto 40900 47955 lineto 40967 48045 lineto 
> 41033 47955 lineto 41100 48045 lineto 41167 47955 lineto 41200 48000 
> linetostroke
> 
> 
> I can work around it by hand-editing the file.
> 
>   -- Don


Could you try applying the attached patch please. I think it is right,
but I've not actually tried it myself - I'm chasing another work task
which is keeping me busy!

If you can confirm this works, I'll either change the "Reported-by", or
add a "Tested-by" with your email address, and push into the repository.

Please also confirm that you're happy for your name and email to appear
in the git log. (I can omit one, other, or both if you don't wish to be
credited in that way).

Best wishes,

Peter Clifton



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gschem postscript bug

[Peter Clifton]

On Wed, 2010-01-27 at 08:32 -0800, Donald Tillman wrote:
> Hey folks,
> 
> In gschem 1.6.0.20091004, I use the File menu to create a postscript
> file for my schematic.  But I can't print or view the file; there's a
> postscript syntax error.
> 
> The problem is that "lineto stroke" is written out as "linetostroke"
> in the .ps file.
> 
> Example here:
> 
> 
> 10 setlinewidth
> 40800 48000 moveto 40833 48045 lineto 40900 47955 lineto 40967 48045 lineto 
> 41033 47955 lineto 41100 48045 lineto 41167 47955 lineto 41200 48000 
> linetostroke
> 
> 
> I can work around it by hand-editing the file.
> 
>   -- Don


Good catch!

Looks like a bug in the path printing code. I'll knock out a fix
shortly.



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: gschem postscript bug

[Donald Tillman]

Hey folks,

In gschem 1.6.0.20091004, I use the File menu to create a postscript
file for my schematic.  But I can't print or view the file; there's a
postscript syntax error.

The problem is that "lineto stroke" is written out as "linetostroke"
in the .ps file.

Example here:


10 setlinewidth
40800 48000 moveto 40833 48045 lineto 40900 47955 lineto 40967 48045 lineto 
41033 47955 lineto 41100 48045 lineto 41167 47955 lineto 41200 48000 
linetostroke


I can work around it by hand-editing the file.

  -- Don

-- 
Don Tillman
Palo Alto, California
d...@till.com
http://www.till.com


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Win32 build with native printing support (via Cairo)

[Peter Baxendale]

I've done a little bit of experimentation but not found much.

I have all the footprints in ./packages, all the symbols in ./symbols
and a local gafrc with (component-library "./symbols") in it.

If I move the packages directory gsch2pcb complains about missing
footprints, so it's finding them. If I move one footprint out of
packages it complains about that one missing footprint, so it's looking
for and finding the right footprint files. Converting projectfile, gafrc
and footprint files to crlf makes no difference.

Looking through the gsch2pcb sources I see that :
/* The gnetlist backend gnet-gsch2pcb.scm generates PKG_ lines:
|
|PKG_footprint(footprint{-fp0-fp1},refdes,value{,fp0,fp1})

These are the lines I see in the pcb file produced by gsch2pcb. Looks
like pkg_to_element() should convert these to elements, but at the
moment I'm struggling to see how or why it doesn't.

Probably doesn't help much...

On Tue, 2010-01-26 at 20:32 -0500, Bob Paddock wrote:
> On Fri, Jan 22, 2010 at 8:21 PM, Kai-Martin Knaak  
> wrote:
> 
> > We already almost do this. The difference: We use a project file and the
> > elements-dir points to the library of my local symbols. Both of Bob
> > Paddocks suggestions might apply. The project file may be affected by the
> > cr/lf problem because it went through a samba server and a windows
> > machine. In addition, the path is located in a path with spaces.
> >
> > Like I mentioned before -- I'll investigate next week.
> 
> Any findings?
> 
> 
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
-- 

Peter Baxendale   University of Durham
peter.baxend...@durham.ac.uk  School of Engineering
tel +44 191 33 42492  South Road
fax +44 191 33 42408  Durham DH1 3LE
  England




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gschem font scaling

[Peter Clifton]

On Wed, 2010-01-27 at 15:48 +0200, Duncan Drennan wrote:
> Hi,
> 
> In geda 1.6.0 the font scaling has changed - is there a way to set the
> font scaling differently? Maybe in a gschemrc file, or does it require
> a recompile?

Recompile, sorry. See libgeda/src/o_text_basic.c

Search:

#define GEDA_FONT_FACTOR 1.3

You probably want it "1.0"


> A brief background to the question:
> 
> Yes, obviously the on screen font has changed significantly due to the
> new font rendering, which is great, but what has also happened is that
> the scaling in the font of a .ps file has also changed.

The on-screen scaling ought not to have changed (much), as the scaling
factor above was designed to match (as closely as possible), the height
of the old gEDA font.

It does mean that postscript output has seen its font size increase (by
a factor of x1.3). Sometimes I still think I made the wrong decision in
doing it that way.

The choice was either smaller on-screen fonts compared to pre gEDA
1.6.0, or try to match on-screen - and increase the postscript output
size.

I really wish I'd fixed 1-1, and just shrunk the on-screen rendering
now. Unfortunately, this isn't something we can easily change back - as
consistency is good.

Technically, it "could" go in a 1.6.1 update - but I suspect there would
be a lot of (valid) opposition to that, since it isn't really a "bug
fix" per-se.

> Pre-cairo/pango the .ps font was significantly smaller than the
> on-screen font, and (IMO) scaled as I would expect it to be. In the
> dev versions 1.5.4 the on screen font matched the old .ps font scaling
> (and .ps font scaling remained consistent). In 1.6.0 it seems the
> decision was to try to approximate the old on screen font size (I can
> imagine some reasons for this - namely symbol library consistency),

 ^
Got it in one there.

> but this has changed the output font size. The change has "broken" of
> my schematics and symbols (my issue, not gEDA's - that's what happens
> when you work with a dev version). I prefer the old scaling, and would
> like to know what I need to change to build it as I would like. It
> would obviously be very nice if this was just a gschemrc setting...

I avoided making if configurable deliberately - since it adds yet
another variable in the already confusing array of settings.

One thing I'm absolutely against is introducing separate on-screen, and
output scalings. gschem is WYSIWYG, and something I think we want to
keep.

I'm not violently opposed to adding a setting for the scaling factor -
but I'd really prefer it wasn't necessary.

> FYI I am working with the win32 builds.

Ok, cool - glad to hear they are working for you.

Best wishes,

Peter C.




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: gschem font scaling

[Duncan Drennan]

Hi,

In geda 1.6.0 the font scaling has changed - is there a way to set the
font scaling differently? Maybe in a gschemrc file, or does it require
a recompile?

A brief background to the question:

Yes, obviously the on screen font has changed significantly due to the
new font rendering, which is great, but what has also happened is that
the scaling in the font of a .ps file has also changed.
Pre-cairo/pango the .ps font was significantly smaller than the
on-screen font, and (IMO) scaled as I would expect it to be. In the
dev versions 1.5.4 the on screen font matched the old .ps font scaling
(and .ps font scaling remained consistent). In 1.6.0 it seems the
decision was to try to approximate the old on screen font size (I can
imagine some reasons for this - namely symbol library consistency),
but this has changed the output font size. The change has "broken" of
my schematics and symbols (my issue, not gEDA's - that's what happens
when you work with a dev version). I prefer the old scaling, and would
like to know what I need to change to build it as I would like. It
would obviously be very nice if this was just a gschemrc setting...

FYI I am working with the win32 builds.

Thanks!
Duncan

-- 
Turn ideas into products - http://www.engineersimplicity.com
The Art of Engineering - http://blog.engineersimplicity.com


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Parts Manager Working Document

[Peter Clifton]

On Tue, 2010-01-26 at 19:15 -0500, al davis wrote:

> Also ..  Do not make the types of electronic components (diodes, 
> resistors) inherent in the data base.  They are just parts, and 
> all parts have schematic symbols, layout footprints, and 
> simulation models.  Don't even try to make any specific device 
> types inherent to the database.

Tagging things with device type (in a consistent way) will certainly
help when you're looking for a part in the database. It needn't be
relevant for simulation - if that's what you mean.

Good database design dictates that the device types are not hard-coded
into the data-structure, there is no explicit "resistors" table JOIN'd
to drag in resistor specific data etc..





___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user