My beef with % encoding is that it is not human readable.  Human
readability is an important goal when designing KiCad file formats.

On 2/16/2018 4:04 PM, Jeff Young wrote:
> Yeah, that’s why I was suggesting %-encoding.  Substituting %20 for spaces 
> wouldn’t be a file format change.  And it’s a common enough escape sequence 
> that anyone writing 3rd-party tools could easily deal with it.
> 
> I think %-encoding is probably better than ‘\’-prefixing, mostly because it 
> can also handle the space issue.
> 
>> On 16 Feb 2018, at 20:56, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>
>> The space issue is tricky because it's not a quoted string.  Quoting the
>> string would be a file format change although you could make the
>> argument so is the space.
>>
>> I believe all of the other strings in question are quoted in the file
>> format so it should just be a matter of quoting any special characters
>> with a '\' character.  That is what I intend to do with the LIB_ID
>> parser and formatter after v5 is released.  This will change both the
>> schematic and board file formats.  That's why I wont do this until after
>> the new schematic file format is implemented so it will be a non issue.
>> An easy solution is to use a validator to veto any forbidden characters
>> from being used where applicable.
>>
>> The other place '/' cannot be used is in sheet names because the human
>> readable sheet path uses '/' to separate each sheet name.  I'm sure
>> there are some other places this issue exists as well.
>>
>> On 2/16/2018 3:32 PM, Jeff Young wrote:
>>> There was an issue a while back where we were considering reverse parsing 
>>> something or another so that spaces didn’t trip us up.  What’s the status 
>>> of that?
>>>
>>> The reason I ask is that I’m looking at another bug where a user wants to 
>>> put ‘/‘ characters in their global labels (which we of course use as a path 
>>> delimiter between sheets and labels.
>>>
>>> In general we need to get our implementation out of the way of users.  So I 
>>> was thinking about applying %-encoding to the label case now, and perhaps 
>>> rolling it out more widely in 6.0.  Which brought me to wondering if it 
>>> would work for the space problem we were having….
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to