Correctly handling multiple filament types that may contain spaces

[gaaat98]

This small fix addresses filament_type parsing from PrusaSlicer based slicers in cases where multiple filament types are used and one or more of these types contain spaces.

When spaces are present in the filament type the slicer surrounds the name with double quotes, which are correctly stripped in case only one type is present. However, for multi-extruder printers this is not the case and it's possible to encounter situations like this:

; filament_type = "PLA Matte";PLA+;PLA+;PLA+

The previous implementation returns 'PLA Matte";PLA+;PLA+;PLA+' which contains a spurious double quote.

Current fix correctly returns 'PLA Matte;PLA+;PLA+;PLA+'

I took a quick look at the other usages of regex_find_string and it seems like removing double quotes altogether shouldn't be an issue.

But why this very minor change is relevant and should be merged? Some printers (cough cough Snapmaker U1) rely on moonraker's metadata parsing for determining if you're allowed to print a given file with the loaded filaments, if there is a name mismatch between the parsed filament types and the loaded ones you will not be allowed to print and instead spend the rest of the evening trying to understand where those pesky double quotes came from.

[Arksine]

Thanks. I suspect that the Snapmaker is running an older version of Moonraker as the issue you are describing was addressed in commit 3a54161, which was merged roughly 3 months ago. The PrusaSlicer implementation of parse_filament_type() no longer calls regex_find_string(), instead it calls regex_find_strings() which performs the split:

def parse_filament_type(self) -> Optional[str]:
    result = regex_find_strings(
        r";\sfilament_type\s=\s(%S)", ",;", self.config_data
    )
    if len(result) > 1:
        return json.dumps(result)
    elif result:
        return result[0]
    return None

The result depends on how many filament types are present. If only one is available the type is returned directly. Otherwise the result is returned as a json encoded array. This was done to keep compatibility with front ends that simply display the result.

As an additional note, the regex_find_string() method is used to parse several fields, and in many of those fields a double quotation mark may be a valid character. If some of these fields were previously populated with quotation marks removing them could potentially break existing front ends that expect them to be there.

[gaaat98]

Thank you for the clarification, it seems indeed that an older version is used, I should have checked better before opening this PR