Permitimos o upload de arquivos SVG no Maker Forums, em parte porque um de nossos públicos-alvo são usuários de gravadores e cortadoras a laser, e os SVGs são comumente usados nesse contexto. Queremos que as pessoas possam fazer o upload deles, tanto para que outros possam baixá-los quanto para visualizá-los durante as discussões. Isso geralmente ocorre no contexto de pedidos de ajuda.
Infelizmente, eles tendem a ser renderizados extremamente pequenos, às vezes praticamente invisíveis. Hoje à noite, alguém fez o upload de um SVG e ele foi automaticamente definido para 12x8 pixels, tamanho tão pequeno que as linhas coloridas desapareceram e a imagem ficou parecida com uma foto de um urso polar em uma tempestade de neve. (Fiquei surpreso que o moderador da categoria tenha notado que havia um SVG ali.) Esse tem sido um problema comum para nós.
Os usuários experientes talvez pudessem aprender que podem, por exemplo, alterar 12x8 para 480x320 para realmente conseguir ver a imagem, mas os usuários experientes geralmente não precisam fazer isso; a maioria das pessoas que postam SVGs são iniciantes buscando ajuda, e elas não conhecem essa peculiaridade do Discourse.
O que faz o Discourse optar por limitar os SVGs a apenas alguns pixels?
Aqui está a consulta que recebi do moderador da categoria, para referência:
Edição: A partir desse tópico, uma possível razão pela qual isso pode afetar este fórum específico mais do que outros:
As cortadoras a laser “K40” comuns têm uma área de trabalho de 12"x8" e operam em incrementos exatos de milésimos de polegada, em vez de usar o sistema métrico. Portanto, usar polegadas é, na verdade, particularmente adequado para esses arquivos SVG; não se trata de algo como “os usuários deveriam usar o sistema métrico”.
Veja como esse gráfico específico aparece aqui (isso não é um pouco de sujeira na sua tela, é o gráfico renderizado):
Vejo exatamente o mesmo tamanho inferido de 12x8 pixels aqui; aqui está o markdown bruto exatamente como mostrado ao fazer o upload deste arquivo, sem nenhuma alteração:
Obviamente, isso exigiu permitir uploads de SVG; minha lembrança é que precisei adicionar svg à configuração authorized_extensions há dois anos ou mais.
Eu vi o código de sanitização de SVG no Discourse. Vejo que eles estão sendo renderizados aqui. Devido ao valor dos SVGs para uma das missões principais do Maker Forums, combinado com a forma como gerenciamos nosso público, escolhemos exibi-los intencionalmente. Quando as pessoas têm problemas para cortar/gravar a laser SVGs, poder ver o SVG no contexto da conversa é uma ajuda valiosa para compreensão e diagnóstico.
Como consegui exibir SVGs aqui no meta também, presumo que você tenha tomado a mesma decisão, embora, obviamente, por um motivo diferente.
Só confirmando que, na investigação, o ponto levantado pelo Scorch acima de que os 12x8 pixels provavelmente não são aleatórios, mas sim devido à falta de tratamento das unidades nos atributos de largura e altura do elemento svg: <svg ... width="12in" height="8in" ...> — eu não tinha percebido isso quando fiz minha primeira postagem.
Você está exatamente certo. A biblioteca que estamos usando para obter os tamanhos das imagens simplesmente pega o valor inteiro dos atributos width e height nos arquivos SVG e não tenta analisar nenhum tipo de unidade. Vou dar uma olhada e tentar encontrar a solução mais limpa para esse problema.
Tenho experimentado alguns dos arquivos problemáticos usando tanto o ImageMagick quanto o librsvg. Parece que o ImageMagick usa um DPI padrão de 96, enquanto o librsvg usa 90. Acho que qualquer um serve, desde que escolhamos um padrão sensato e nos mantenhamos nele…
90 ou 96 fariam com que os SVGs com largura e altura não apenas em polegadas, mas também em mm, tivessem um tamanho mais razoável. Atualmente, os SVGs com largura e altura em mm são exibidos basicamente com 1 mm por pixel do navegador, aparecendo em uma escala de aproximadamente ⅓ a ¼. Antes, eu apenas encolhia os ombros e dizia: “Bom, é escalável, supongo…” mas, se você puder adicionar tanto polegadas quanto mm com uma resolução padrão razoável, isso fará com que ambos sejam renderizados muito melhor.
O HTML para e-mail é um conjunto tão restrito (para não mencionar implementado de forma inconsistente; veja o Litmus) de HTML, e vocês destacam que o Discourse foi criado para a web moderna (por exemplo, rolagem infinita), então eu não tinha consciência de que a representação completa em e-mail de tudo o que poderia ser representado na web era uma consideração central. Essa é uma nova nuance para eu entender. (Eu poderia imaginar que, dadas recursos infinitos, alguém pudesse renderizar SVG para PNG para incluir em e-mails, o que teria uma fidelidade maior do que muita da besteira necessária para e-mails HTML em geral, mas com o SVG não habilitado por padrão, isso parece muito baixo como prioridade…)
@Neotinker teve a ideia de, em algum momento, usar o onebox com threejs para incorporar modelos 3D interativos nas conversas do Discourse sobre esses modelos; algo que gostaríamos de ativar para os Fóruns de Maker, caso isso se torne uma funcionalidade. A consideração de que “não é possível renderizar isso no e-mail” atrapalharia a aceitação de tal trabalho, caso ele ou outra pessoa implemente? (Observo que o threejs usa o Discourse para o próprio fórum…)
Ou, se isso for mais uma questão de priorização sobre quanto tempo o CDCK quer dedicar a esse problema, ficaria feliz com um apontamento para o código; não quero implicar que estou impondo um fardo aqui. Vocês viram, nas minhas contribuições anteriores, que não sou especialista em Ruby ou RoR, mas estou disposto a colocar isso na minha fila de coisas para analisar. (Postei esse tópico originalmente antes de perceber que estava descartando unidades e assumindo pixels, então achei que era uma decisão de design, foi por isso que o coloquei em Contribute > UX em vez de Contribute > Bug)
Criei um pull request na tarde de sexta-feira que deve resolver o problema de arquivos SVG ficarem minúsculos quando as dimensões são expressas em polegadas, centímetros, milímetros ou unidades similares.
O pull request está aguardando revisão de código e, portanto, ainda não está disponível, mas deverá estar pronto em breve.
Obrigado por compartilhar o commit para que eu pudesse ver onde e como foi feito!
Desculpe, interpretei mal o @codinghorror — achei que ele quis dizer que tudo havia se transformado em um problema sem fim, e não foi minha intenção criar muito trabalho aqui.
