From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Wed Jul 22 2009 - 11:51:25 CDT
On 7/22/2009 6:15 AM, Alexander Kempgen wrote:
> I was wondering if there are format characters or other ways to mark
> parts of a word or words, that can automatically be shortened, if the
> text has to fit in a smaller space when displayed in a software
> application.
>
As far as I know, there is no format character that is designed for that
purpose, and many would say that is a good thing - because the more
format characters exist, the more difficult it would be for "simple"
software to handle such text - having to step past all the irrelevant
format characters.
If you are talking about handling strings that are only ever meant to be
handled by one application, then you could use one of the 66
noncharacter code points for the purpose. They are FDD0..FDEF,
FFFE..FFFF, 1FFFE..1FFF etc to 10FFFE..10FFFF.
These are for _internal use_, which would fit your proposed application
perfectly.
An alternative to noncharacter code points, is "light-weight" markup.
This is used in many user interfaces today. Windows uses the & character
as a command to underline a character in a menu and turn it into a
keyboard shortcut. You could use "$" and modify your software that it
treats a single $ as an abbreviation location, but uses two $$ or \$ as
a real dollar sign. For unabbreviated strings, it would filter single $
signs, so they are not visible.
So far, all approaches are valid and useful, if you are trying to solve
a problem for *your* piece of software, and none of the strings are
shipped around and have to be interpreted by other software that isn't
in on the secret.
If this turns out to become a more common, widespread problem, with the
need to widely and safely share data that is marked up like that, then
there are two options:
a) create or extend a markup language to handle this information (go
beyond plain text)
b) convince the UTC that this is of similar importance to, say, the soft
hyphen, and ask for a standardized code
Because many user interface systems already use special, ad-hoc
conventions, and because this has not caused problems, I rather think
that going with an implementation or platform specific approach should
be your first try.
A./
This archive was generated by hypermail 2.1.5 : Wed Jul 22 2009 - 11:54:33 CDT