Maker 포럼에서는 레이저 각인기 및 컷터 사용자 커뮤니티가 존재하며, 이러한 장비에서 SVG 파일이 널리 사용되기 때문에 SVG 업로드를 허용하고 있습니다. 우리는 사용자들이 다른 사람들이 다운로드할 수 있도록, 또는 토론 과정에서 볼 수 있도록 SVG를 업로드할 수 있기를 바랍니다. 이는 주로 도움이 필요한 요청의 맥락에서 이루어집니다.
불행히도, SVG는 극도로 작게 렌더링되는 경향이 있으며, 때로는 거의 보이지 않을 정도로 작아지기도 합니다. 오늘 밤 누군가가 SVG를 업로드했는데, 자동으로 12x8픽셀로 설정되어 컬러 라인이 사라질 정도로 작아졌고, 마치 눈보라 속의 북극곰 사진처럼 보였습니다. (카테고리 모더레이터가 아예 SVG가 있다는 것을 알아챈 것 자체가 놀라웠습니다.) 이는 우리에게 흔한 문제였습니다.
경험 있는 사용자들은 예를 들어 12x8을 480x320으로 변경하여 실제로 이미지를 볼 수 있다는 것을 배울 수 있을 것입니다. 하지만 경험 있는 사용자는 대부분 이렇게 할 필요가 없으며, SVG를 게시하는 대부분의 사람은 이 Discourse의 특이한 점에 대해 모르는 도움을 구하는 초보자들입니다.
Discourse가 SVG를 몇 픽셀에 불과하도록 제한하도록 만드는 원인은 무엇일까요?
참고로, 카테고리 모더레이터로부터 받은 쿼리는 다음과 같습니다:
수정: 해당 스레드에서, 이 문제가 다른 포럼보다 이 특정 포럼에 더 큰 영향을 미칠 수 있는 가능한 이유가 있습니다:
물론 SVG 업로드를 허용해야 했습니다. 제 기억으로는 2년 전쯤 authorized_extensions 설정에 svg를 추가해야 했던 것 같습니다.
Discourse에서 SVG 정제(sanitization) 코드를 확인했습니다. 여기서는 렌더링되는 것을 볼 수 있습니다. Maker 포럼의 핵심 사명 중 하나인 SVG의 가치와 우리의 사용자 기반 관리 방식을 고려하여, 우리는 의도적으로 SVG를 표시하도록 선택했습니다. 사람들이 SVG를 레이저 절단/각인하는 데 어려움을 겪고 있을 때, 대화 맥락에서 SVG를 볼 수 있는 것은 이해와 진단에 있어 매우 유용한 도움이 됩니다.
제가 meta에서도 SVG를 표시할 수 있었던 점을 볼 때, 아마도 당신도 동일한 결정을 내린 것으로 보입니다. 물론 이유는 분명히 다를 것입니다.
조사를 진행하면서, 위에서 Scorch가 언급한 12x8 픽셀의 값이 우연한 것이 아니라 svg 요소의 width와 height 속성에서 단위를 처리하지 않아서 발생한 것일 가능성이 높다는 점을 확인하고 싶었습니다. 처음 질문을 올릴 당시에는 그 사실을 인지하지 못했습니다.
정말 정확히 지적해 주셨습니다. 이미지 크기를 가져오기 위해 사용하는 라이브러리는 SVG 파일의 width와 height 속성에서 정수 값만 가져오고, 단위 유형을 파싱하려는 시도는 하지 않습니다. 이 문제를 가장 깔끔하게 해결할 방법을 찾아보겠습니다.
문제가 있는 파일 몇 개를 ImageMagick과 librsvg를 모두 사용하여 실험해 보았습니다. ImageMagick은 기본적으로 DPI 96을, librsvg는 90을 사용하는 것 같습니다. 합리적인 기본값을 선택하여 일관되게 적용하기만 하면 어느 쪽이든 괜찮을 것 같습니다…
90dpi 또는 96dpi를 사용하면, SVG의 너비와 높이가 인치뿐 아니라 밀리미터 단위일 때도 더 합리적인 크기로 표시될 수 있습니다. 현재 밀리미터 단위로 너비와 높이가 지정된 SVG는 기본적으로 브라우저 픽셀 1개당 1mm 비율로, 즉 약 ⅓~¼ 배율로 표시됩니다. 이전에는 “그래도 확장 가능한 거니까…” 하고 넘겼지만, 인치와 밀리미터 모두를 합리적인 기본 해상도로 지원해 주시면 두 단위 모두 훨씬 더 잘 렌더링될 것입니다.
이메일 HTML은 매우 제한적인 (그리고 비일관되게 구현된; Litmus 참조) HTML 집합이며, 여러분은 Discourse가 현대적인 웹(예: 무한 스크롤)을 위해 만들어졌다는 점을 강조하고 있습니다. 저는 웹에서 표현할 수 있는 모든 것을 이메일에서 완벽하게 표현하는 것이 핵심 고려 사항이라는 사실을 전혀 인지하지 못하고 있었습니다. 이는 제가 이해해야 할 새로운 쟁점입니다. (무한한 자원이 있다면 SVG를 PNG로 렌더링하여 이메일에 포함할 수 있을 것이라 상상해 볼 수 있습니다. 이는 일반적으로 HTML 이메일에 필요한 많은 무의미한 처리보다 훨씬 높은 충실도를 제공할 것입니다. 하지만 SVG가 기본적으로 비활성화되어 있어, 이는 우선순위로서 훨씬 낮게 느껴집니다…)
@Neotinker는 언젠가 threejs를 사용하여 Discourse 대화에 인터랙티브한 3D 모델을 임베드하는 onebox를 구축하는 아이디어를 가지고 있었습니다. Maker Forums가 실제로 기능으로 존재하게 된다면 이를 활성화하고 싶은 것이었습니다. 만약 그분이나 다른 누군가가 이를 구현한다면, "이메일에서 이를 렌더링할 수 없다"는 고려 사항이 이러한 작업을 수용하는 데 장애가 될까요? (참고로 threejs가 자신의 포럼에 Discourse를 사용하고 있습니다…)
아니면 이것이 CDCK가 이 문제에 얼마나 많은 시간을 투자할지에 대한 우선순위 결정 문제라면, 코드에 대한 안내를 주시면 감사하겠습니다. 여기서 부담을 주려는 의도는 아닙니다. 이전 기여를 통해 보셨듯이 저는 Ruby나 RoR 전문가가 아니지만, 검토할 일들의 큐에 추가할 의향이 있습니다. (제가 원래 이 토픽을 게시했을 당시에는 단위 유실과 픽셀 가정 문제가 디자인 결정이었을 것이라고 생각하여, Contribute > UX 대신 #contribute:bug에 넣지 않았습니다 )
