코드 블록은 이메일의 HTML 부분에서만 각 줄 사이에 빈 줄이 삽입되어 있는 것처럼 보입니다. 포럼 자체와 이메일의 일반 텍스트 부분에서는 올바르게 표시됩니다. 이는 이메일 서식/CSS 문제가 아닙니다. 이메일의 경우에만 소스에 실제로 줄바꿈이 삽입되고 있습니다.
예시: [iFFT Freeze/Scrub - #25 by toneburst - Questions - scsynth]
게시물의 원본 소스 텍스트는 다음과 같습니다:
웹사이트에서 포맷된 게시물은 다음과 같습니다:
그러나 수신된 HTML 이메일은 다음과 같이 보입니다:
이메일 소스를 보면 모든 줄바꿈이 두 배로 되어 있는 것을 확인할 수 있습니다:
동의합니다. 이 부분은 꽤 어색해 보입니다.
@techAPJ 조사해 주시겠어요?
2.9.0.beta1에서 전송된 이메일에서 여전히 문제가 보입니다. 그 이후에 수정되었다면 나머지 내용은 무시해 주세요 
이 문제는 특정 이메일 클라이언트와 관련이 없습니다. 제가 올린 두 번째 스크린샷은 이메일에 생성되는 원시 HTML입니다. 하지만 실제로는 이메일의 실제 내용(일부抜粋)을 살펴보는 것이 더 많은 정보를 제공합니다:
<pre style=3D"word-wrap: break-word; max-width: 694px;"><code style=3D"di=
splay: block; background-color: #f9f9f9; overflow: auto; padding: 5px;; b=
ackground-color: #f9f9f9; padding: 2px 5px;">=0D
(=0D
// This expects two keys to be defined: ~history (the list) and ~recordKe=
y (which key to record)=0D
Pdef(\keyRecorder, Pbind(=0D
\callback, Pfunc({=0D
|event|=0D
event[\callback].addFunc({ // combine your record func with any previou=
s callback that was there (it's okay if its nil)=0D
~history.add(currentEnvironment[~recordKey])=0D
}).postln;=0D
})=0D
));=0D
=0D
명백히 (a) 코드에서 줄바꿈이 있어야 할 위치에 실제 줄바꿈이 있고, (b) 모든 줄의 끝에 =0D 문자(캐리지 리턴)가 있는 것을 볼 수 있습니다. AFAIK(제 지식으로는) <pre> 태그 안의 모든 줄바꿈은 문자 그대로 해석되어야 하므로, 이것이 이중 줄바꿈의 원인입니다.
Gmail에서 이 문제를 재현할 수 있으며, 이메일 메시지의 HTML 부분을 브라우저에서 직접 열어서(=0D와 같은 quoted printable 문자를 대체한 후) 확인할 수도 있습니다. 이로 인해 궁금한 점이 생겼습니다:
=0D)를 확인하시나요?=0D 문자(또는 줄바꿈)를 제거하고 있는 것일까요?어쨌든, Gmail에 특정한 문제일지라도 Gmail은 압도적으로 가장 일반적인 이메일 클라이언트이므로, 이 문제를 살펴볼 가치가 있을 것입니다.