Non vedo un grande cambiamento visibile (anzi, non ne vedo affatto!). Presumo che sia perché i due set si assomigliano molto?
Non ho ancora finito, ma ci sono quasi:
L’idea di base è che le emoji di Fluent UI hanno tutte un margine attorno all’immagine per consentire varie forme. Il margine necessario è variabile, ma hanno applicato un valore fisso a ogni immagine, rispetto ad altri set che non hanno margini, il set di Fluent UI sembra più piccolo a causa di questo.
Ho lavorato a una pipeline per calcolare il bounding box più ottimale per ogni emoji, il che dovrebbe comportare un’emoji più grande e fluida. Spero di averla unita domani.
Dolce! È lo stesso per tutti i set? Chiedo perché le reazioni sul tuo sito sono piuttosto più grandi di quelle sul mio. Attualmente sto lasciando provare agli utenti Twemoji. Questo è lo stesso monitor e lo stesso browser fianco a fianco. Apri in una nuova scheda per vedere le dimensioni grandi.
![]()
no solo openmoji è anche influenzato da questo, per quanto ne so. Dovrò guardare il tuo sito per capire la differenza.
Ho guardato e sembra essere correlato al tuo tema che ha questo css:
html {
font-family: ember-regular, sans-serif;
font-size: 14px;
}
La dimensione delle emoji è relativa alla dimensione del carattere di base, quindi nel tuo caso hai ridotto la dimensione del carattere di base e di conseguenza le tue emoji sono più piccole.
Capito. Grazie per aver dato un’occhiata!
Non capisco come venga distribuito. Sulla mia versione 3.5.0.beta2-dev, il set “Twitter” è attualmente attivo con Apple, Windows 10, Google Classic e Facebook Messenger come selezioni. Vedrò le nuove opzioni dopo un nuovo deployment del web container?
Seconda domanda: come posso aggiungere il set openmoji? (curiosità: l’università che ha progettato questo si trova a pochi chilometri da casa mia nel sud-ovest della Germania)
Sì, apparentemente ti mancano gli ultimi commit.
Openmoji sarà già disponibile nell’elenco quando aggiornerai. Tuttavia, openmoji è piuttosto impegnativo a causa della loro scelta di avere un ampio margine, il set appare piuttosto piccolo. Sto cercando di applicare una soluzione simile a quella che ho usato per fluentui, ma a causa di alcune differenze nel modo in cui sono definiti gli svg, per ora non funziona altrettanto bene.
Dopo tutti questi anni in cui abbiamo apprezzato la grafica delle emoji Apple sul nostro Discourse, posso chiedere quali siano stati questi motivi di licenza che le hanno fatte scomparire improvvisamente, per favore?
Non abbiamo l’autorizzazione esplicita per usarli.
C’è un modo per aggiungere l’emoji della mela come set di emoji personalizzato e poi selezionarlo come impostazione predefinita?
In modo che i messaggi esistenti non perdano la loro visualizzazione?
Al momento scusa, potremmo rendere più facile aggiungere il tuo set in futuro se vuoi, ma non mi aspetto che succeda presto.
Sarei felice di co-sponsorizzare questo su Marketplace se vuoi discuterne @taravasya?
Tecnicamente fattibile secondo
Il feedback che stiamo ricevendo per la perdita del vecchio set Apple è davvero pessimo.
Verificherò, grazie ![]()
Sembra abbastanza semplice da implementare, ci sono dettagli o guide sulle convenzioni di denominazione per le immagini emoji?
Potrei trovare la risposta in un commit che elenca tutte le immagini che sono state eliminate dal repository?
Mi dispiace non poter rispondere nel tuo argomento collegato, è bloccato ![]()
Sono riuscito a recuperare la maggior parte delle emoji Apple e a farle funzionare seguendo quella guida, ma ci sono un sacco di 404 che vengono generati.
Cose come :grinning_face:
e :weary_cat:
e :kissing_face:
generano un 404/Non trovato perché non esistono nel set Apple su https://github.com/discourse/discourse/tree/stable/public/images/emoji/apple
Per ora l’ho disattivato di nuovo.
Facciamo molte cose per garantire la massima compatibilità, se vuoi procedere in modo personalizzato, dovrai gestire vari problemi come questo.
Penso che il modo più semplice per risolvere i 404 potrebbe essere copiare/incollare l’intero set di Twemoji sopra la cartella /apple/ e dirgli di non sostituire l’immagine se esiste già.
Sono aperto a suggerimenti se qualcun altro sta cercando di risolvere questo problema ![]()
sì, è quello che facciamo nel gem, copiamo da unicode poiché unicode è supposto avere sempre l’immagine in quanto sono il riferimento sorgente
