On Sep 28, 2010, at 7:25 PM, kai-martin knaak wrote: > >> One of the things that attracted me to gEDA years ago was how >> clean and concise the documentation was. > > Coincidently, some of the my most frustrating experiences with geda/pcb > were due to a lack of readily available documentation ;-)
You and I have very different ideas of what constitutes good documentation. If I'm visiting a new country, a map is far more useful that a book of narrative directions to get from place to place. Give me a little narrative to get me started, then give me a map and let me figure it out. That's the high productivity route, and I'm tremendously grateful that gEDA, bucking the trend to comfortable fritterware, supports it. Fortunately, gEDA isn't commercial software, so user comfort can have lower priority than productivity. > > >> Works fine with UTF-8 characters, although I don't know how to >> make it work right to left or top to bottom. > > Well, Hebrew left to right is like Latin script written backwards. Sure. I worked on an early Hebrew/Arabic document processing system in the 1970's. It's unclear how to do that within gEDA and its underlying graphical tools. > Also, try to make auto number use Japanese digits... Except that Japanese engineers don't use kanji for that purpose anyway. Writing R三 for a refdes would be like Rthree in English. Japanese would use R3. Is there any engineering culture that uses a system different from the latin-arabic system commonly used for this like this? > > >>> Multi line text cannot be >>> centered or flushed to the right. >> >> Fancy word processing features should not be included in a >> schematic drawing program. They are a distraction. > > Text alignment is hardly fancy word processing. Decent looking comments > are a requirement when it comes to incorporate a schematic in public > documents. Think PHD thesis, presentations, manuals, proposals... I import gEDA graphics into TeX for this purpose. Let gEDA do what it does best, let TeX do what it does best. > > >> Support for unusual graphics does not belong in gschem. They >> can be imported in the rare cases they are needed. > > A company logo is not exactly a rare case. Also, publication quality > symbols are more like fonts than like stick drawings. But gEDA supports the import of graphics, so you can do this. > > >> Well, I just drew the following, which would claim is impossible: > > Well, an imported pixel format does not exactly fit to the workflow of > an otherwise completely vectorized suite. But that's inconsistent with your view above. If I want my company logo on a schematic, I must import pixels: it's based on an astronomical image. Similarly, the "stick drawings" you complain about are a consequence of using a vector format. > For example, printing to PDF > via cups-pdf barfs on PNGs. But export of graphics to PS works pretty well in gEDA. Specialized tools need not and should not support every graphics format. There are plenty of graphics conversion tools. > > Real flexibility would allow to include vector graphics and/or a way to > do formulas. The way xfig incorporates LaTeX may be worth a closer > look. That's real *inflexibility*. gEDA should work with tools like LaTeX without any specialized connection. Users should not be required to use LaTeX, make, or any other specific tool, but should be able to easily get gEDA to cooperate with these tools, and others, if they fit their flow. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
