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 de e-mail é um conjunto tão restrito (para não mencionar a implementação inconsistente; veja o Litmus) de HTML, e vocês enfatizam que o Discourse foi criado para a web moderna (por exemplo, rolagem infinita), que não tinha consciência de que a representação completa em e-mail de tudo o que poderia ser representado na web fosse uma consideração central. Essa é uma nova nuance para eu entender. (Posso imaginar que, com recursos infinitos, alguém poderia renderizar SVG para PNG para incluir no e-mail, o que teria maior fidelidade do que muita da besteira exigida para HTML de e-mail em geral, mas com o SVG não ativado por padrão, isso parece muito baixa como prioridade…)
@Neotinker teve a ideia de, em algum momento, usar o onebox com o threejs para incorporar modelos 3D interativos nas conversas do Discourse sobre esses modelos; algo que gostaríamos de ativar para Fóruns Maker, caso alguma vez exista como recurso. A consideração de “não pode renderizar isso em e-mail” atrapalharia a aceitação de tal trabalho se ele ou outra pessoa o implementasse? (Observo que o threejs usa o Discourse para seu próprio fórum…)
Ou, se isso for mais uma questão de prioridade sobre quanto tempo a CDCK quer dedicar ao problema, ficaria feliz com uma indicação do código; não quero implicar que isso seja um ônus aqui. Vocês viram em minhas contribuições anteriores que não sou especialista em Ruby ou RoR, mas estaria disposto a colocar isso na minha lista de coisas para analisar. (Postei este tópico originalmente antes de percebermos que ele estava descartando unidades e assumindo pixels, então pensei que fosse uma decisão de design, motivo pelo qual o coloquei em ux em vez de 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.
