X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9kvsmrBEmewlmXTgAU5WXK4puLOO2Gv+kNPbQ2epz9c=; b=hZd/1lCQH9B7WCf9BKNT3gTY3My9oIMS3xGyJ1pKwmyhBRrgmoJlO1WAzBOp2njcIl v1C++ZMa4htinvJMX9fkSo/603psugvZFmR0EBROgbx+emmlsdXfJuC31G+cbXXIKCfP fG9OM3widhtC+AcOl+/mVz3uvmOItbfpwRkMBuM2y/DQqwVfAqVA5ndc6dkUQl5FO6EQ dLHQT5JmeBtJPjaMDH5X+DKFNTewmUq0C71IWxTexpcoze7oBrkvc1ZoaN1VFW4dXrh+ 30GRSzkjZtyKl85+u9+wQHTmn1wRpbV5mbFsu26qcouJhm0v8o15pg5TWOz0TvMyt+2K RJWQ== MIME-Version: 1.0 X-Received: by 10.52.28.146 with SMTP id b18mr2100434vdh.55.1409941489679; Fri, 05 Sep 2014 11:24:49 -0700 (PDT) In-Reply-To: <201409051752.s85Hqnr2027362@envy.delorie.com> References: <201409051618 DOT s85GIdb8024685 AT envy DOT delorie DOT com> <5409F1C2 DOT 3090406 AT xs4all DOT nl> <201409051752 DOT s85Hqnr2027362 AT envy DOT delorie DOT com> Date: Fri, 5 Sep 2014 14:24:49 -0400 Message-ID: Subject: Re: [geda-user] Chinese glyph rendering in pcb as symbols From: Jason White To: geda-user AT delorie DOT com Content-Type: text/plain; charset=UTF-8 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 On Fri, Sep 5, 2014 at 1:52 PM, DJ Delorie wrote: > UTF-8 is the way to go. It's backwards-compatible with ASCII. IMHO, > at this point it's foolish to contemplate anything else. > >> One thing I can foresee is that pcb files with Chinese fonts will >> become larger. > > We'd need a way to refer to an external font somehow, but then we have > the problem of PCB files no longer being idempotent. > > Embedding large fonts might only be practical if we switch to a binary > format that can embed the compressed font as-is, but we'd need a way > to convert to-from text format, or use a container like zip, to work > with existing tools that want a plain text file. I think zip would certainly be the most flexible path, that way you can keep the human readable layout files and include whatever fonts or images are required without inserting huge ASCII-encoded binary blobs all over the place. The tools and scripts would still work, all you'd have to do is feed them the text file from the zip. This also could (if one was so inclined) provide a means of isolating the various components of a design, footprints, symbols, etc. from the particular system or environment so that they travel with the file. Element definitions could be moved to an internal folder in the zip called "elements". This might also facilitate the creation of self contained libraries. Which would be a boon to users I'd think. -- Jason White