X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f Date: Tue, 22 Sep 2015 16:56:43 -0400 Message-Id: <201509222056.t8MKuhcX010513@envy.delorie.com> From: DJ Delorie To: geda-user AT delorie DOT com In-reply-to: (message from Roland Lutz on Tue, 22 Sep 2015 18:22:14 +0200 (CEST)) Subject: Re: [geda-user] Apollon the technical thread References: <20150921001659 DOT 0c211170 AT jive DOT levalinux DOT org> <55FF3F4B DOT 8000406 AT jump-ing DOT de> <20150921225908 DOT 480bde74 AT jive DOT levalinux DOT org> <201509220522 DOT t8M5M6WF010656 AT envy DOT delorie DOT com> <20150922065143 DOT GA25726 AT visitor2 DOT iram DOT es> <1442935680 DOT 677 DOT 19 DOT camel AT ssalewski DOT de> 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 Perhaps a compromise - store the font name and extents for each string, and if you have to substitute, you can at least clip the new rendering to the old extents so they won't intersect anything else that they didn't intersect before. Plus, we could make a font substitution a hard error in an exporter, unless you give some command line option to OK it. We'd have to come up with good rules for when to update the saved extents to match the "current" ones, though. Perhaps a warning popup if the text is moved or changed and the old extents didn't match? There's no reason we can't use polygons in exporters to render fonts any different than what we see on screen, and we'd need a REALLY good reason to do that ahead of time and save the results anywhere.