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