From: Johannes M. <js...@su...> - 2019-12-05 09:14:27
|
Hello, On Dec 4 11:30 Solomon Peachy wrote (excerpt): > On Thu, Dec 05, 2019 at 12:49:54AM +0900, Protea Wines Japan wrote: >>> Yup, the RU strings tripping the errors are 49 characters taking up 88 >>> bytes. CUPS has a hardcoded upper limit of 80 characters for these >>> strings. > > (Bah, even I can't get bytes/characters correct in a single paragraph..) > >> Ouch .Implied bytes here I guess, if the spec was for 1-byte chars? > > Yeah, the spec just treats them as opaque byte sequences. > >> Yes, nasty. In PHP, he mb_ functions are the solution, online there >> are plenty of howto's on cutting off correctly in UTF-8, but messy. I >> assume we are talking about C code here? Any chance of some library or >> function that can handle cutting off correctly? > > It's a minor PITA, but when we generate the PPDs we can properly > truncate the strings based on PPD_MAX_TEXT. > > But truncated strings aren't desireable for the user; the bit chopped > off might be the only part that differs from other strings. > > I think the only sane short-term approach is to adopt a policy to keep > all translated strings under 80 bytes. Careful with truncating UTF-8 strings! Only plain 7-bit ASCII "just works" simple and fail-safe. Making UTF-8 "just work" is neither simple nor fail-safe (except "just work" means to "just abort" when there is any string that is not a valid UTF-8 byte sequence ;-) If a truncated string (e.g. in a print job option value) is no longer a valid UTF-8 byte sequence, CUPS may reject the whole print job in "strict conformance" mode" or CUPS may alter invalid values to some arbitrary fallback in "relaxed conformance" mode so that the job may print but with different printout result as what was intended. Cf. https://github.com/apple/cups/issues/5143 and https://github.com/apple/cups/issues/5186 Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer |