X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Cam-AntiVirus:	no malware found
X-Cam-ScannerInfo:	http://www.cam.ac.uk/cs/email/scanner/
Message-ID:	<1410040265.27594.1.camel@cam.ac.uk>
Subject:	Re: [geda-user] Chinese glyph rendering in pcb as symbols
From:	Peter Clifton <pcjc2 AT cam DOT ac DOT uk>
To:	geda-user AT delorie DOT com
Date:	Sat, 06 Sep 2014 22:51:05 +0100
In-Reply-To:	<201409060357.s863vvBL013729@envy.delorie.com>
References:
	<CAHUm0tMk1cQm_DPVt_swzTGDA+FRL-37fUougH_3hNaqwR_LOQ AT mail DOT gmail DOT com>
	<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>
	<CAOFvGD5S+Gw_TPiuu3VkT53jvLewZbiP6f2BTaFRhJJP7Ai-1Q AT mail DOT gmail DOT com>
	<20140905184829 DOT GH3196 AT cicely7 DOT cicely DOT de>
	<CAOFvGD5NT=mCa24GEfv2UKGam29-h47Q3NFdcx9Gw=pg3n49=g AT mail DOT gmail DOT com>
	<20140905204312 DOT GJ3196 AT cicely7 DOT cicely DOT de>
	<540A22EF DOT 5030701 AT estechnical DOT co DOT uk>
	<201409052113 DOT s85LDfxf001064 AT envy DOT delorie DOT com>
	<CAM2RGhRGb+Vzq8kH1NX=DrZZP7DMMu8b50LkLtsk6-jxYp-DyA AT mail DOT gmail DOT com>
	<CAHUm0tO5ZAE4FM0HF3TvK0LJVEP5ZHGPz6C_fTEvsLMqjdGquw AT mail DOT gmail DOT com>
	<201409060357 DOT s863vvBL013729 AT envy DOT delorie DOT com>
X-Mailer:	Evolution 3.12.4-0ubuntu1
Mime-Version:	1.0
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

On Fri, 2014-09-05 at 23:57 -0400, DJ Delorie wrote:
> The whole point of UTF-8 is that we don't need something to tell UTF-8
> strings from ascii strings :-)
> 
> Symbol['<ascii character>']
> Symbol['<utf8 character>']
> 
> And I don't think storing hundreds, if not thousands, of glyphs in the
> *.pcb file as Symbol[]s, makes any sense at all.  We really need to be
> able to read a *.ttf file directly if we're going to support large
> fonts.
> 
> > If the PCB file format becomes binary,
> 
> I think a zip file is OK, because lots of OSS projects use zip, and
> the internal file is still ascii anyway so you can always extract it.
> Best of both worlds :-)

Actually, I've seen zip files with non-compressed content...

The zip header lies at the end of the file, so at the very least - one
could append binary data and a zip structure at the end of the
conventional PCB file.

I think (but haven't checked), that it would be possible to force
non-compressed content as part of the actual zip file, so perhaps that
might be a way to strike a balance between revision control capable, and
adding structuring content into the file.

I'm not sure whether the zip header uses absolute offsets into the file
(if so, that would hamper direct editing of the file), but it might be
worth looking into.

-- 
Peter Clifton <peter DOT clifton AT clifton-electronics DOT co DOT uk>

Clifton Electronics

- Raw text -