kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

This would even work for footprint file names so we could use illegal
file name characters in footprint names although it would be a bit
verbose.  It definitely would be more readable than using hex numbers.
It is definitely something I would consider.

On 9/28/2018 2:56 PM, Jeff Young wrote:
> We could use the entity-reference strategy for that.  A real ‘{’ would get encoded as “{openbrace}”, so any braces in the encoded string are known to be encoded-character-clauses.
> 
>> On 28 Sep 2018, at 16:21, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>
>> I prefer readability over verbosity as long as the verbosity isn't too
>> excessive.  We are still going to have to provide some type of escaping
>> no matter how you look at it.  If you are going to use something like
>> {quoted_character} you still have to provide escaping of the '{' and '}'
>> characters.
>>
>> On 09/28/2018 09:07 AM, Jeff Young wrote:
>>> For the illegal filename chars I think we’re going to be forced into some sort of encoding as escaping will still leave the illegal chars there.  The question then becomes do you prioritize verbosity or readability:
>>>
>>> my_project{slash}library
>>>
>>> my_project%2Flibrary
>>>
>>> my_project0x2Flibrary
>>>
>>>
>>>
>>>> On 28 Sep 2018, at 12:50, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>>
>>>> That would solve the colon problem but not the other illegal file name
>>>> characters such as '/' and '\'.  I would like to have a fix for all of
>>>> the characters that we currently convert to '_'.  I suppose that we
>>>> could use a solution like this for all illegal characters but it would
>>>> be a bit verbose (read less human readable).
>>>>
>>>> On 09/27/2018 04:31 PM, Jeff Young wrote:
>>>>> Right, but that only requires changes to the LIB_ID parser because the ‘:’ character still appears in the escape sequence.
>>>>>
>>>>> Imagine that we encoded it as “lib_name_with{colon}:item_name{colon}with_colon”, then no changes in parser required, and older versions of kicad would handle it OK (they’d just display the longer syntax in dialogs, etc.).  Newer versions could show the shorter syntax (just the ‘:’) everywhere it wasn’t ambiguous.
>>>>>
>>>>>> On 27 Sep 2018, at 19:25, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>>>>
>>>>>> Hey Jeff,
>>>>>>
>>>>>> In this case you are going to have to prevent the colon character from
>>>>>> being using in LIB_ID names because the LIB_ID parser uses the colon to
>>>>>> separate the library name from the item name.  I was thinking that we
>>>>>> could quote the colon so that a string like
>>>>>> "lib_name_with\:_colon:item_name\:with_colon" would be parsed as a
>>>>>> library named "lib_name_with:colon" and an item named
>>>>>> "item_name:with_colon.  This requires a change in the LIB_ID parser and
>>>>>> formatter and and libraries created this way would not be compatible
>>>>>> with older versions of kicad.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Wayne
>>>>>>
>>>>>> On 9/27/2018 2:05 PM, Jeff Young wrote:
>>>>>>> Hi Wayne,
>>>>>>>
>>>>>>> Yes, I was around for the quoting discussion, but this current idea was not just for spaces but for filename-illegal-characters as well.  Instead of quoting:
>>>>>>>
>>>>>>> this is my/filename
>>>>>>>
>>>>>>> we could write out:
>>>>>>>
>>>>>>> this&nbsp;is&nbsp;my&fasl;filename
>>>>>>>
>>>>>>> which uses XML-entity-references and doesn’t require any file-format changes.  There’s also %-encoding (commonly used in URLs) which would look like:
>>>>>>>
>>>>>>> this%20is%20my%2Ffilename
>>>>>>>
>>>>>>> While neither is terribly readable, it’s a corner case and if the user really wants odd characters in their names then it’s about all we can do.
>>>>>>>
>>>>>>> But then I ran into the ‘:’ problem.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jeff.
>>>>>>>
>>>>>>> PS: I’m still OK with the “punt” option; I just wanted to explain that it doesn’t need any file format changes.
>>>>>>>
>>>>>>>
>>>>>>>> On 27 Sep 2018, at 17:49, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> We cannot change LIB_IDs until the new schematic file format is
>>>>>>>> implemented because the symbol LIB_ID is not saved as a quoted string.
>>>>>>>>
>>>>>>>> In pcbnew, the footprint library name is the file name so that is all
>>>>>>>> together different issue.  We can quote file names like urls but we
>>>>>>>> still have to change the LIB_ID parsing and formatting to handle this in
>>>>>>>> the board file which would effectively require a file format change.
>>>>>>>>
>>>>>>>> I'm pretty sure we've discussed this as part of v6 but maybe that was
>>>>>>>> before you joined the project.  Long story short, abandon the idea until
>>>>>>>> all the pieces are in place to implement it correctly.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Wayne
>>>>>>>>
>>>>>>>> On 9/27/2018 12:15 PM, Jeff Young wrote:
>>>>>>>>> I had planned to get rid of another of our nanny items (“illegal” characters in names).  The plan was to escape these strings coming in from the UI, and unescape them going out to the UI (or to canvas painting routines).
>>>>>>>>>
>>>>>>>>> But I ran into a snag: we let you edit the FPID in the GUI, and that has the colon in it.  So there’s no way to know whether a colon coming in from that is the separator or needs to be escaped.
>>>>>>>>>
>>>>>>>>> Things we could do:
>>>>>>>>>
>>>>>>>>> 1) abandon the idea
>>>>>>>>> 2) do everything but colon
>>>>>>>>> 3) present FPIDs unescaped in the GUI
>>>>>>>>> 4) something else more clever than what I’ve come up with
>>>>>>>>>
>>>>>>>>> If we do (2) or (3), there’s also the question of the encoding system.  %-encoding is the easiest, but the least human-readable.  An entity-encoding-style syntax with our own names (cf: &forward-slash;) would be the most human-readable, but isn’t standard.  Entity-encoding using XML names (cf: &fasl;) is somewhere in between (and is what I’d lean toward).
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Jeff.
>>>>>>>>> _______________________________________________
>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>
>>>
>