Bug #61
closed
pstoedit on osx fails to write valid .lgc file when /usr/local/share/pstoedit/laoscfg.ps is in use
Added by m.winkler almost 12 years ago.
Updated almost 12 years ago.
Description
see
drvlaos.cpp
129 #ifdef APPLE
130 RSString test("/usr/local/share/pstoedit");
131 #endif
132 #ifndef APPLE
133 RSString test(drvbase::pstoeditDataDir());
134 #endif
this makes pstoedit find laoscfg.ps on OSX
the problem is just if it is found correctly generated .lgc file looks something like the attached one,
if it is not found i get an error for that, but the .lgc is generated with default settings as defined in drvlaos.cpp,
something while reading laoscfg.ps must set the psfeatures to odd
Files
i have pinpointed the problem in drvlaos.cpp
142 globaloptions_p.nameOfIncludeFile.copyvalue_simple(test.value());
if i comment that line, i get a working .lgc
if not it opens /usr/local/share/pstoedit/laoscfg.ps and i get an empty .lgc
i attached a gdb log
Looks like you made some progress! Can we do something to help?
after tinkering a little bit with /usr/local/share/pstoedit/laoslaser.cfg i found the evil bugger
36 /pstoedit.hidestroke {
37 % these are the vectors that should not show up in the drawing, as they are used for cutting/marking:
38 pstoedit.blackline pstoedit.redline or
39 pstoedit.thinline and
40 } def
if this lines are deleted everything works,
any suggestions ? anyway i keep hunting
- Status changed from In Progress to Closed
ok i got all confused here, in fact the latest pstoedit works on OSX 10.7 and creates good lgc files .
I had always seen the lgc files with the long
9 .... .... .... ... etc
commands so i thought that the commands are always that long ( that where only bitmap data )
i figured it when i read the documentation about the file format.
anyway i close the bug
It's not a bug, it's a feature!
It defines that thin lines will be cut, not engraved. Pstoedit.hidestroke defines the thickness and color of the cutting-lines.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by