gEDA-user: [RFC 3/6] Embedding system revamp

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

gEDA currently allows symbols or pictures to be embedded in a
schematic. However, the current embedding system requires the full
data to be embedded for each instance of an embedded item.

This has a number of shortcomings:

1. It bloats filesize by requiring multiple redundant copies of the same
   data.

2. It makes updating embedded symbols a hassle, especially if you
   accidentally miss one copy of a particular symbol.

3. It is limited in terms of the filetypes that can be
   embedded. Although I can't currently think of any reason to embed
   file types other than images, symbols or (possibly) schematics, one
   might crop up in the future.

I propose that a schematic or symbol file explicitly embed each embedded
file once only, to then be referred to each time a component or picture
object instantiates that file.

File load algorithm
-------------------

Loading a file would procede according to the following algorithm:

1. File is parsed. Embedded files are stored, and component or picture
   objects are *not* expanded.

2. For each picture or component object:

   (a) If the filename specified is present in the store of embedded
       files, the embedded file is instantiated.

   (b) Otherwise, use the current mechanism for determining how to load
       image or symbol data.

Note that this allows embedded objects to be placed at the end of the
schematic or symbol file.


File format changes
-------------------

An embedded file would have the following syntax:


          E <filename> <size> <type> [<transfer-encoding>]
          <data>


The <filename> would be the filename of the file being embedded. The
<type> would be the Internet media type of the file, and the optional
<transfer-encoding> would be the encoding used to store the <data>. If
the <transfer-encoding> is not specified, the <data> is assumed to be
literal UTF-8 text. [*] The <size> parameter is the number of octets in
the encoded <data>, not including a trailing newline character.

Is this sensible? Should we use MIME boundaries to delimit the data
rather than a <size> field?


Handling older files
--------------------

The new and old embedding formats would not be permitted to both appear
in a file. The v version header of the schematic file would be used to
determine which form of embedding format to expect.

If a file with the older syntax is loaded:

1. For each embedded object found:

   (a) The embedded data is parsed.

   (b) If its filename does not exist in the store of embedded files,
       the file is stored.

   (c) Otherwise, generate a new filename based on the original
       filename, and add to the store of embedded files. Update the
       picture or symbol to point to the new filename. Is there a more
       elegant way of handling this case?

2. As normal file load algorithm above.


Notes
-----

This system would mean that if you embed one instance of a given symbol,
all instances of that symbol would be embedded. Is this desirable? (I
think it is).


[*] Note that we may also consider making gEDA files officially use CRLF
    line-endings, for better compatibility with 'quoted-printable'
    encoding & Windows users.


                              Peter

-- 
Peter Brett

Electronic Systems Engineer
Integral Informatics Ltd


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