Não vejo uma grande mudança visível (na verdade, não vejo nenhuma!). Presumo que seja porque os dois conjuntos parecem muito semelhantes?
Ainda não terminei, mas estou perto:
A ideia básica é que os emojis do Fluent UI têm uma margem ao redor da imagem para acomodar várias formas. A margem necessária é variável, mas eles aplicaram um valor fixo em todas as imagens, em comparação com outros conjuntos que não têm margens, o conjunto Fluent UI parece menor por causa disso.
Tenho trabalhado em um pipeline para calcular a caixa delimitadora mais otimizada para cada emoji, o que deve resultar em um emoji maior e mais suave. Espero ter isso mesclado amanhã.
Doce! É o mesmo para todos os conjuntos? Pergunto porque as reações no seu site são bem maiores do que as do meu. Atualmente, estou deixando os usuários experimentarem o Twemoji. Este é o mesmo monitor e o mesmo navegador lado a lado. Abra em uma nova aba para ver em tamanho grande.
![]()
não, apenas o openmoji também é afetado por isso, pelo que sei. Terei que olhar o seu site para entender a diferença.
Eu verifiquei e está relacionado ao seu tema, que tem este CSS:
html {
font-family: ember-regular, sans-serif;
font-size: 14px;
}
O tamanho dos emojis é relativo ao font-size base, então no seu caso você reduziu o font-size base e, como resultado, seus emojis ficaram menores.
Entendi. Obrigado por dar uma olhada!
Não entendo como isso é implementado. Na minha versão 3.5.0.beta2-dev, o conjunto “Twitter” está atualmente ativo com Apple, Google, Windows 10, Google Clássico e Facebook Messenger como seleções. Verei as novas opções após uma nova implantação do contêiner web?
Segunda pergunta: como posso adicionar o conjunto openmoji? (curiosidade: a universidade que projetou isso está localizada a poucos quilômetros de minha casa no sudoeste da Alemanha)
Sim, aparentemente você está perdendo os commits mais recentes.
O Openmoji já estará disponível na lista para você quando você atualizar. No entanto, o Openmoji é bastante desafiador devido à sua escolha de ter uma grande margem, o conjunto parece bem pequeno. Estou tentando aplicar uma solução semelhante à que usei para o Fluent UI, mas devido a algumas diferenças na forma como os SVGs são definidos, não está funcionando tão bem por enquanto.
Depois de todos esses anos aproveitando os visuais dos emojis da Apple em nosso Discourse, posso perguntar quais foram esses motivos de licenciamento que fizeram com que eles desaparecessem repentinamente, por favor?
Não temos autorização explícita para usá-los.
Existe alguma maneira de adicionar o emoji de maçã como um conjunto de emojis personalizado e então selecionar esse conjunto como padrão?
Para que as mensagens existentes não percam sua aparência?
Neste momento, desculpe, poderíamos facilitar a adição do seu próprio conjunto no futuro, se você quiser, mas não esperaria isso em breve.
Eu ficaria feliz em co-patrocinar isso no Marketplace se você quiser discutir @taravasya?
Tecnicamente factível por
O feedback que estamos recebendo por perder o antigo conjunto da Apple é muito ruim.
Vou verificar isso, obrigado ![]()
Parece simples o suficiente de implementar, existem detalhes ou guias sobre convenções de nomenclatura para as imagens de emoji?
Posso encontrar a resposta para isso em um commit que lista todas as imagens que foram excluídas do repositório?
Desculpe, não posso responder no tópico vinculado, ele está bloqueado ![]()
Consegui fazer a maioria dos emojis da Apple voltarem a funcionar depois de seguir esse guia, mas há um monte de 404 sendo lançados.
Coisas como :grinning_face:
e :weary_cat:
e :kissing_face:
estão lançando um 404/Não encontrado porque não existem no conjunto da Apple em https://github.com/discourse/discourse/tree/stable/public/images/emoji/apple
Desativei novamente por enquanto.
Fazemos muitas coisas para garantir a compatibilidade máxima, se você quiser seguir o caminho personalizado, terá que lidar com vários problemas como este.
Acho que a maneira mais fácil de resolver os 404 pode ser copiar/colar todo o conjunto Twemoji sobre a pasta /apple/ e dizer para não substituir se a imagem já existir.
Aberto a sugestões, caso mais alguém esteja tentando resolver isso também ![]()
sim, é o que fazemos no gem, copiamos do unicode, pois o unicode deve sempre ter a imagem, já que é a referência de origem.
