Hi Kevin, On Thu, Nov 05, 2020 at 08:43:42AM -0800, Kevin J. McCarthy wrote: > On Thu, Nov 05, 2020 at 04:47:20PM +0100, Gero Treuner wrote: [...] > > So the space between the encoded words is not shown, > > Yes, this is correct according the section 6.2 which Arnt mentioned. > > > while the space between an encoded word and not encoded words is shown. > > Also correct. > > > For me it is not clear why Mutt splits the word "Große" into parts of 4 > > + 1 characters, whether the different cases for display of space are > > specified somewhere, which approach from above might be followed in > > Mutt etc.
Thanks for finding and pointing out the specifying section. The comment probably wants to say that an implementation should not be burdened to care about spaces on both sides - uencoded and encoded words - within subsequent text to be encoded. Then the logic and also my case is compliant to the standard, although it is not ideal to cut within plain text words when there is enough remaining space on the line, forcing the second part of the word to be encoded regardless of the content, to prevent the space after the first encoded block to be displayed. Then probably choose_block () is to be checked for optimization. According to this the display issue on iOS is clearly a bug on their side. Gero
