X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Mon, 18 Jul 2016 02:13:45 +0200 (CEST) From: Roland Lutz To: geda-user AT delorie DOT com Subject: Re: [geda-user] New XML file format for schematics and symbols In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1962476018-1468800825=:1534" Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1962476018-1468800825=:1534 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 17 Jul 2016, Kai-Martin Knaak wrote: > What happens if xorn is presented with a box command that has the > parameters x= and y= swapped? I'd expect the utility to silently read > the values into their corresponding internal representation. Or is there > some chatter in the logs? The XML file is parsed using Expat which handles this transparently. You can arrange the attributes in any way you like, including additional whitespace and even line breaks between the attributes (but not within an attribute). The attributes which are listed in the format description as having a default value can be omitted. > What happens on save? Does xorn try to keep the order of the parameters > as in the original. Or does it rearrange the parameters into some > "official" order? The logical contents of the file are the only information which is kept after reading the file is finished. When saving them, a new XML document is constructed which contains exactly this information. (This kind of abstraction is exactly the point of the Xorn storage library.) > I'd prefer the latter as it straightens irregularities introduced by > manually messing with the contents. But I can certainly see why people > would advocate for the former. (Maybe, the user deliberately rearranged > the order. Keep changes to the file to a minimum to keep version control > lean) I did consider this, but not too seriously. Doing this would be *much* more complicated, and I'm not aware of any other piece of software which does this. >> When converting .sch files to XML files, the symbols and pixmaps >> referenced by the schematic are included in the XML file by default. > > this is equivalent to the "embed" action from within gschem, right? No, it's not. If you apply the "embed" action on a component or picture in gschem, it basically gets its own copy of the original symbol or pixmap which is saved within the schematic file and used instead of the original file. This corresponds to the "embedded" reference mode in the XML format. The "referenced" reference mode, in contrast, treats the symbol or pixmap saved within the XML file as informational, only to be used if the original file isn't available. You could e.g. use this mechanism to compare the original file with the one saved within the XML file and print a warning if they don't match (i.e., the referenced file has been changed). > So this command does not interpret the traditional geda way to tell > where the libs are. (gafrc, gnetlistrc at their various locations) That's correct. The Xorn commands don't execute any Scheme code, and I'd like to establish that as a standard for any new gEDA-related work. >> When using the default library included with gEDA, you can't use >> --symbol-library-search=, unfortunately, because it contains symbol >> name conflicts. > > Can you elaborate, please? When a gEDA/gaf tool is started up, the standard library isn't added as a whole using (component-library-search ...), but one subdirectory at a time using (component-library ...), with the exception of the directories "gnetman", "verilog", and "vhdl" which are, according to a comment, "commented out […] because there are conflicting filenames within these libraries." xorn.geda treats symbol name conflicts as an error because which of the homonymous symbols should be used is undefined, and undefined behavior is undesireable, especially in the context of EDA software. --8323329-1962476018-1468800825=:1534--