Hi Simon,
I have accumulated a considerable number of replace lists since I began using TextPipe.
Almost all of them are encoded as UTF-8 without BOM.
You're not telling me that I should have to change most of them and check/debug previously working filters, are you?
That would be a huge chore that I have not planned as part of my workload.
Many of them are used as Perl pattern replacements, with UTF-8 support ticked.
The latter is because the Files to Process are mostly UTF-8 themselves.
So if I don't use something with UTF-8 support, the files being processed get corrupted.
The phrase "backwards compatibility" springs to mind.
Surely, you owe it to your customers at least to provide an option that will not cause well-established filters to break?
Moreover, what about the longstanding descriptions in the
pattern matching reference?
2. In a pattern, the escape sequence \x{...}, where the contents of the braces is a string of hexadecimal digits, is interpreted as a UTF-8 character whose code number is the given hexadecimal number, for example: \x{1234}. If a non-hexadecimal digit appears between the braces, the item is not recognized. This escape sequence can be used either as a literal, or within a character class.
3. The original hexadecimal escape sequence, \xhh, matches a two-byte UTF-8 character if the value is greater than 127.
According to this, as an alternative, I should have been able to use \x{00AB} and \x{00BB) in the replace list file. Yet in version
8.9.2 this doesn't work either.
Neither did \x{ab} and \x{bb}, so the help reference I've been using to solve issues with naive replacements is also "broken".
That was one of the first things that I tried before reverting to v8.8.2 to find out what on earth was happening.
Best regards,
David
Best regards,
David
