[aprssig] Symbol set revisions
Heikki Hannikainen hessu at hes.iki.fiThu Apr 17 07:21:43 UTC 2008
- Previous message: [aprssig] APRS Situational Awareness
- Next message: [aprssig] Symbol set revisions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi everyone, Stephen H. Smith wrote: > 3) Decreeing new symbols is not a trivial task. It's a very large task, especially since every application uses it's own file formats for mapping the symbol characters to the respective images, and each application requires it's own image formats, too. I'm not sure, but it seems to me that it requires plenty of manual work from someone to update each and every application to support a new symbol set. I know it's a large pain for me to fix aprs.fi to support a new modified set. Lots of manual work. And I'm not exactly sure which source should I trust to be *the* definitive standard for current symbols. Is it Bob's symbolsX.txt, or should I look at what other applications are actually using? For now, I'm inclined to go for most compatibility with others. I don't personally care so much about the contents of the symbol set. But I think it's not wise to modify it every year, because that way the symbol sets in applications will never be synchronized. Even if the applications would be updated, the users will not be upgrading a working installation of an application (unless the application automagically makes it really easy or unavoidable, like modern Linux and Windows versions do). If it is modified, it should be made as easy as possible for everyone to update their applications. This requires two technical things: 1) A machine-readable configuration file, which has an extendable and parseable format, which will not require changing the configuration file format when new attributes are added. symbolsX.txt is as far as possible from this. symbols.ini is slightly better, but not extendable, and it relies on "magic" prefix strings in the descriptions, and you cannot have a ',' in the description. There are good formats out there. XML is one but not necessarily the most lightweight one. symbols.ini is close to CSV but not quite extendable. 2) A single standard source for the symbol images, so that everyone doesn't need to draw their own. The standard config file should clearly point to the symbol images in a clearly defined way. The images should be in a format which is easy to convert to the formats used by each application, and be of sufficient quality for everyone to use. They should have consistent transparency, for one (transparent color per symbol image file, or an alpha channel). The symbol image files should be downloadable from a single place, as a single archive file (zip?) containing the images in a standardized file structure / directory tree, *and* the configuration file which maps each image to the symbol table/character. I'd be happy to put in updated symbols every 3 months, but only if I wouldn't have to manually figure out which symbols have changed, and where can I find the new images, and what I need to do to convert them to an usable format. If the symbol images + configuration format would be standardized well, and stored in a good static place on the web (always the same URL, not some person's home directory, but maybe TAPR's web or something) it would be possible for each application to download an updated set and install it automatically for the user. Much like the current satellite tracking software downloads kepler files from somewhere and installs them without bothering the user. It'd even be possible to write an ui-view addon to do this. > The alpha-numeric overlay character assignments (recently discussed on this > list) are even more of a problem. The only Windows application that even > renders overlay characters is UI-View. I'd like to implement them in the aprs.fi service, but for browser performance reasons I'll have to pre-render all the overlay characters on top of the symbol images, and on top of the pre-rendered *rotated* symbol icons too (applicable only for symbols which are rotatable). If it would be possible to automate importing new symbol sets, I'd be happy to automate the overlay rendering, too. - Hessu, OH7LZB
- Previous message: [aprssig] APRS Situational Awareness
- Next message: [aprssig] Symbol set revisions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
