[aprssig] spaces in object names

[Lynn W. Deffenbaugh (Mr)]

I'm not weighing in on either side of the debate, but simply adding an 
indisputable fact on the matter (hence the quote of WHICH C runtime I 
was using).  When someone says "printable" to me (being a C programmer), 
I automatically think of isprint() as the "gospel" standard (at least, 
according to C).  As for whether it "prints" anything, I would consider 
head movement on an old dot matrix printer to be "printing" something, 
especially if it prints something else later that shows up (like an 
embedded space would cause).  However, that's just my opinion.

If I ever code APRS software that allows a user-specified object name, 
I'll enforce the then-current standard.  If I had done it in the past, 
it would have been a check against isprint().  Luckily, my current 
software doesn't create objects, but simply displays them.

As for display software, while they may be ambiguous in a proportionally 
spaced font, if the object comes through APRS (or APRS-IS), I'll display 
it to the best of the platform's ability.  As for uniqueness, trailing 
blanks certainly aren't part of unique, but embedded spaces would 
certainly be considered so.

Now, if an "invalid" object is non-displayable for some reason 
(out-of-bound coordinates for instance), then I'd suppress it from the 
display, but an ID with embedded spaces would certainly be displayable, 
albeit potentially not clearly.

Lynn (D) - KJ4ERJ - Just adding my $0.02 on how to handle the existing 
objects



Steve Dimse wrote:
> The issue is not which side is right. Wikipedia says it is not. The 
> fact is, it is debatable. If you want to debate it with someone else, 
> feel free.
>
> The issue is this ambiguity creates a problem with the use of APRS, 
> and it needs to be resolved. If we had been aware of this ambiguity it 
> would have been clarified in spec 1.0. Instead, it is clarified in 
> 1.2. But it is clarified.
>
> If someone were in court being charged with "Delivery of illegal 
> packets" I absolutely agree that they should be acquitted. We are not 
> running a trial, I am not blaming anyone for doing this, it is just a 
> different interpretation of an unexpectedly ambiguous phrase. Time to 
> clarify and move on.
>
> The original intent was that spaces should not be embedded in objects, 
> and that has now been mabe explicit.
>
> Steve K4HG
>
>
> On Aug 12, 2009, at 5:16 PM, Lynn W. Deffenbaugh (Mr) wrote:
>
>> According to the Watcom C runtime library function isprint(), "Space 
>> is printable".
>>
>> Lynn (D) - KJ4ERJ
>>
>> PS.  Simple program to ask...
>>
>> #include <ctype.h>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>>   printf("Space is %s\n", isprint(' ')?"printable":"NOT printable");
>>   return isprint(' ');
>> }
>>
>>
>> Steve Dimse wrote:
>>> It has recently come to my attention that DStar objects are being 
>>> sent to APRS with an embedded space in the object name (like "K4HG 
>>> A"). The APRS spec states that objects names can be any printable 
>>> character. As it turned out this is a poor choice of words. 
>>> Surprisingly to me, whether space is printable is debatable. When I 
>>> searched Google, the first entry (wikipedia) and some others very 
>>> clearly state it is not a printable character. Other pages state it 
>>> is a printable character. This sort of ambiguity is obviously not 
>>> desirable in the spec document.
>>>
>>> It never occurred to me to consider it printable, so my parser 
>>> removed all spaces as a lazy way to get rid of trailing spaces. This 
>>> obvious broke with these objects, the object "K4HG A   " became 
>>> "K4HGA". This was obviously a bug, and I've corrected it to match my 
>>> interpretation of the spec, namely object "K4HG A   " is invalid. I 
>>> continue to remove trailing spaces.
>>>
>>> The problem is readability. If you do not remove trailing spaces, 
>>> there can be six different entities on map that print as "K4HG", 
>>> distinguished on whether they have zero to five spaces after my 
>>> callsign. This is a problem for the tactical use of APRS. The same 
>>> argument applies to embedded spaces, where the number of spaces can 
>>> be difficult to judge with a proportional font.
>>>
>>> I've discussed this with Bob and he agrees, and will be making this 
>>> clarification on the spec addendum page. In looking over the log for 
>>> the last couple hours, I only see DStar objects with embedded 
>>> spaces, so there should not be any problems to other users from this 
>>> clarification.
>>>
>>> Those sending DStar objects, the easiest change to make would be to 
>>> simply replace the embedded space with a dash, so K4HG A becomes 
>>> K4HG-A.
>>>
>>> Steve K4HG
>>>
>>> _______________________________________________
>>> aprssig mailing list
>>> aprssig at tapr.org
>>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>>
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>