Resolving of postScriptName in XD-API. #26

Open scoiatael opened 1 year ago

In GitLab by @nikitamironov on Mar 18, 2020, 16:13

Tady bych sepsal vsechny mozne pohledy na tuhle vec. Osobne se mi zda, ze muzeme narazit na situaci, kdy ten font nebude existovat ani lokalne, ani u nas - v takovyhle situaci nevim co presne muzeme udelat. Honza rika, ze to neni problem (ale chapu to asi tak, ze to neni problem pro rendering) - nevim jestli je to problem pro writery a jine mista vyuziti Octopusu (napr Ceros). V komentech bych pokracoval v diskuzi.

In GitLab by @evzen on Mar 18, 2020, 16:50

local resolution

Resolving PSName directly in XD Plugin would almost certainly require a local HTTP server, which seems like an overkill to me.

But if we make a list of fonts used in the design in the plugin, and send it over to Avocode App, then the App can quickly fetch all the necessary PSNames.

The converter is then provided with a map of fonts/styles to PSNames. I think it will be enough to cover the vast majority of designs. If the designer doesn't have a font locally, XD shows a warning (about the missing font) and renders the text in some default font anyway.

backend resolution

Where are we going to get those fonts names from? Can we keep PSNames in our database and update it when we have a new font? How difficult would it be to implement? Is there a big benefit in doing this?

However, if we ever need to make these designs "uploadable" using the web app, then it's of course the only way.

In GitLab by @janroztocil on Mar 18, 2020, 17:55

Par poznamek za me:

Predem je dulezity rict, ze kdyz nam XD ten postScript name neda, tak ho proste mit nebudem i kdybychom se postavili na hlavu.

Samozrejme jsou zpusoby jak se k nemu zkusit dostat, ale zadnej neni bullet-proof. Moznosti jsou:

Zkusit najit font lokalne na pocitaci uzivatele a pouzit hodnotu z nej, to bude fungovat kdyz uzivatel, ten font u sebe skutecne ma.
Pouzit nasi fontovou servicu, aby se o nejaky resolve pokusila na zaklade dat, co ma k dispozici, to ma ale nekolik problemu: predevsim ze to spoleha na nejakou online servicu, coz vytvari problem s lokalnim (offline) processingem, taky neni jasny z jakych dat tu informaci brat? pokud jen z privatnich dane organizace, tak co delat kdyz tam nikdo z organizace dany font zatim nenahral; anebo ze vsech fontu v databazi? tady zas nechcem, aby se uzivatele vzajeme ovlivnovali - at uz v dobrem (maji komercni font) nebo ve zlem (nahrali tam bullshit), taky je otazka jaky by to melo smyslo pro privatni cloudy, ktere nemaji pristup k fontum vsech uzivatelu.
Neresit to vubec, nechat to bud prazdne nebo vygenerovat nejaky placeholder nebo to odvodit syntakticky z font name/font style (to odvozeni samozrejme nedava vzdy spravne postScript name), a vyresit to az pozdeji, kdyz to bude skutecne treba; to by teda chtelo podporu ve Schriftmeisterovi (zvlast pro ty prazdne hodnoty). Melo by to ale tu vyhodu, ze by se dalo zjistit "spravne" jmeno az z toho fontu, ktery uzivatel uploadne, a pak bud zpetne updatnout octopus nebo to aspon poskytnout skrze api pro pripadny zajemce.

Takze se nabizi otazka...

Proc vlastne potrebujeme spravny postScript name?

Historicky to bylo proto, ze jsme chteli uzivatelum najit ten nejlepsi font mezi vsema na svete, bez toho, aniz by pro to cokoliv udelali. To ukazalo jako problematicky, protoze mezi "vsema fonty na svete" je i spoustu nesmyslu, ktere se ale nedaji dost dobre odhalit. Proto nova fontova servica prenechava odpovednost na uzivateli, ktery font nahraje (pocita se automatizaci toho procesu samozrejme). A v ten moment tedy je celkem jedno, co je skutecne postScript name, staci, kdyz to bude syntakticky validni identifikator, to je vse.

Pokud jde o subsytemy, ktere postScript name potrebuji, tak ktere to jsou?

Rendering? Ten to pouziva jen proto, ze to ma po chce schriftmeister v API jinak je mu to jedno.
Writery? Muzou se na to zeptat servicy nebo najit lokalne nebo rict, ze proste nevi.
Kdo dalsi? Code panel v appce? To je stejny pripad jako writery.

Takze k zamysleni

Jak moc velky je problem, kdyz by konvertor zavisel na vzdalene service?
Je mozne zpatky propsat postScript name do octopusu? (to je dost bezprecedentni, mozna trochu podobne injectoru)
Jak moc je dulezite, aby postScript name odpovidalo presne tomu puvodnimu fontu?

In GitLab by @janroztocil on Mar 18, 2020, 18:00

However, if we ever need to make these designs "uploadable" using the web app, then it's of course the only way.

@evzen, do budoucna pujde pouzit tohle: https://inexorabletash.github.io/font-enumeration/ zatim ale nevim jak moc je to podporovane v browserech

In GitLab by @janroztocil on Mar 18, 2020, 18:02

Jen pro kontext se zeptam, ten problem (ze chybi postScript name) je jen u XD pluginu? Nebo ho prestanou davat i do .xd filu? @nikitamironov, @evzen?

In GitLab by @nikitamironov on Mar 18, 2020, 18:31

@janroztocil co ja vim tak zatim se to tyka jen XD API.
Jeste tu bych rad slysel co si o tom mysli appka (@jankuca), @petrbrzek, a @rychlis.

In GitLab by @nikitamironov on Mar 18, 2020, 18:41

Nektere argumenty Honzy nechapu, napriklad ze muze nastat konflikt pri resolvovani globalne (bez organization scope). Nebo vlastne chapu, ale nejsem si jisty ze to je to nejhorsi - protoze aspon neco bude asi lepsi nez nic. Videl bych mozna takovyhle postup:

zkusit resolvnout lokalne
pokud lokalne nejde, zkusim jestli mam moznost obratit se na backend
2.1 pokud nemam internet nebo nemuzu nejakym zpusobem zapojit do toho backend, tak proste bod 3.
2.2 pokud mam internet, tak backend zkusi organization-scope nejdriv
2.3 pokud v organizaci neni, zkusit globalne
pokud ani backend nemuze najit nebo nemame internet, tak zkusit synteticky vytvorit:
```
syntheticPostScriptName: true,
postScriptName: `${name}-${style}`
```

In GitLab by @nikitamironov on Mar 18, 2020, 18:42

Nebo pokud vlastne my uz postScriptName nepotrebujem cist ze sourcu vubec, ale prenasime zodpovednost za nahrani fontu na uzivatele - tak potom ani neni co resit, muzeme tu vlastnost proste skipovat.

In GitLab by @petrbrzek on Mar 18, 2020, 19:03

1) Souhlas s Evzenem. Logiku bych necpal do pluginu a kdyz uz, tak bych to nechal na appku, ktera je mnohem svobodnejsi v tom co muze.

2) Pokud by Octopus nepotreboval postScriptName, tak bychom proste mohli uploadnout vsechny fonty, ktere nam na zaklade font family pripadaly relevantni a UI v appce by se prizpusobilo tak, ze by user mohl na klientovi jednoduse menit jako font se pouziva.

In GitLab by @nikitamironov on Mar 18, 2020, 19:26

@petrbrzek takze chapu spravne, ze budeme posilat samotne fonty (ktere odpovidaji kombinaci name + style) + vlastne mapku ktera bude reprezentovat neco jako {[psname]: [name, style]}?

In GitLab by @evzen on Mar 18, 2020, 19:35

diky, nevedel jsem.

issue: https://bugs.chromium.org/p/chromium/issues/detail?id=535764

TLDR: z diskuze jsem pochopil, ze i ve Figme by to chteli. Implementace jen zacina

In GitLab by @nikitamironov on Mar 18, 2020, 20:39

petrbrzek:

Hele postscript name appku urcite nezajima kvuli code panelu. 
Tam se proste vypisuje font-family.
Nevytvarel bych ani zadny synteticky postscriptname pokud to neni nutny. 
Proste bych ukladal ten font name a font style a nase service bude 
zodpovedna za spravny picknuti fontu. V UI v appce by taky mohl byt 
chooser, ktery by ti dovoloval zmenit jaky font se pouzije.

nikita:

okay, tak potom asi evzen by nemusel mit s tim zadne starosti teda, right?
jakoze proste to tam neda a je to cele?

petrbrzek

jj
Rad bych aby tohle jeste posvetil Honza Roztocil, ptz on vi nejvic o te font service.

In GitLab by @nikitamironov on Mar 18, 2020, 21:41

Ptal jsem se jeste Honzy Kuci a jeho response je:

Pokud subfamily=style, tak je technicky možný to podle toho načítat. Vyžaduje to ale změnu ve font loaderu v appce a změnu API stage včetně util, co nám říká, jaké fonty stage chce pro daný octopus. V tom panelu záleží na tom, jestli nějaký jazyk (css/cssinjs/reactnative/android/…) používá postscriptname místo fontfamily+style, protože jinak nevim, k čemu by to tam mělo být. Vim, že je to tam i jako fallback, že pokud nemáme family, tak se vypíše postscriptname, ale to by se teda asi dalo zrušit.

poznamka: subfamily to je to co se ted pouziva v appce pro resolvovani fontu lokalne pro stage.

In GitLab by @jankuca on Mar 18, 2020, 21:42

Nn, subfamily se teď nepoužívá pro resolve. Je to jen interní údaj pro načtení fontů z disku. Pro resolve se momentálně používá postscriptname, ale je možné to vyměnit právě za subfamily name (pokud by byla spolehlivá shoda s údaji v octopusu).

In GitLab by @janroztocil on Mar 19, 2020, 10:07

@nikitamironov

Nektere argumenty Honzy nechapu, napriklad ze muze nastat konflikt pri resolvovani globalne (bez organization scope)

Ja ale nikde nepisu nic o zadnem konfliktu, ja jenom tvrdim, ze je zbytecne pouzivat verejnou databazi fontu, pro resolve postScript name. Jednak proto, ze to musi zaviset na online service (coz je sice dulezity, ale uznavam, ze a hlediska diskuze o fontech trochu OT), ale spis proto, ze ten vysledek proste muze byt spatne. Proto nesouhlasim s tim, ze neco je lepsi nez nic. Kdyz nejaky random uzivatel nahraje font, co ma normalni family a style, ale psname treba Adolf, tak se pak uzivatel bude docela divit, az mu appka ukaze dialog, ze mu chybi zrovna Adolf... ono to teda zpravidla nebude takhle spatny, ale spis tam budou bud jmena v azbuce nebo cinstine (to standard nedovoluje, ale obcas se takovy font objevi) nebo ruzne zmanglovany jmena jako OpenSans-W17, ArialRg, atp... coz neni takova hruza, ale zamezi to ty kontrole v appce, ze uploadujes spravny font.

Ja ale jinak souhlasim s tim postupem co @nikitamironov psal, akorat bych vynechal ten bod 2.

Obecne bych se ale postScript name nezbavoval, to co jsem psal plati pro ten pripad, kdy ho proste nemame, tvrdim, ze se bez nej dokazeme obejit (kdyz to doimplementujem teda). Ale v ostatnich pripadech se hodi, je to primocary idetifikator, na kterem se vetsina toolu shodne, pouziva se v API ve schriftmeisteru i v renderingu; a hlavne je nezbytny v pripadech, kdy zas nemame family a style (Sketch napr.).

Proto mi pouziti toho syntetickeho postScript name jako fallbacku prijde uplne v pohode. Na mistech, kde se to chape jen jako identifikator, nevadi, ze neni presne, a v mistech kde zalezi na ty vlastni hodnote (modal v appce pro upload napr.), tak tam se bude respektovat ten 'synthetic' flag a ukaze se family/style.

In GitLab by @vojtatranta on Mar 19, 2020, 10:15

Říkal jsem Nikitovičovi, že mně je celkem jedno, jestli tam bude nebo nebude postscript name. Nám jde v apce o to, abychom dokázali ten font z designu identifikovat s fontem z file systemu. Je jedno, jestli přes postscript name nebo přes něco jiného.

To je vám ale určitě jasný.

In GitLab by @rychlis on Mar 19, 2020, 11:01

Varianta nemit v octopusu vubec postscriptname - to by bylo dobry odhadnout, jak dlouho bude trvat implementace. Sice se teoreticky da obejit bez postscriptname, ale bylo by potreba upravit hromadu komponent:

Appka by musela zmenit urcite kod ohledne zobrazeni font dialogu a uploadovani fontu, aby nevyzadoval postscriptname
Muselo by se upravit API v manageru a schriftmeisteru na upload fontu, aby nevyzadovalo postscriptname
V manageru je logika ktera po tom co nahrajes z appky font, projde vsechny ostatni artboardy v design filu a trigguruje prerenderovani artboardu kterym tenhle font chybel. Ted se spoleha na seznam chybejicich postscriptnames ve vystupu rendering-workeru, coz predpokladam nebude dostupny. Muselo by se to taky zmenit
Zmena api ve schriftmeisteru pro rendering worker na ziskani fontu na zaklade font family & name.
Uprava rendering-workeru aby umel volat zmenene api schriftmeisteru pro ziskani fontu

Takze mi taky prijde taky lepsi smer to co rikal honza roztocil, postup od nikity bez bodu 2:

Ja ale jinak souhlasim s tim postupem co @nikitamironov psal, akorat bych vynechal ten bod 2.

Teda:

zkusit resolvnout lokalne
pokud font neni lokalne, synteticky vytvorit postscriptname

XD ti ted ani nevyrenderuje textove vrstvy spravne pokud font neni lokalne dostupny (nahradi text layer fallback fontem) a krici na tebe ze ti chybi font. Tak mi prijde, ze ani user nebude ocekavat ze vyrenderujem text vrstvu spravne, kdyz mu chybi lokalne font a ani XD tu vrstvu nevyrenderuje spravne. Tak mi prijde ze pouzivat lokalni fonty by melo fungovat celkem spolehlive, ale mozna se pletu?

Jak komplexni bude resolvovat lokalne font a predat tu informaci do pluginu? Mate nejakou predstavu, jak by to mohlo fungovat? Napada me bud:

Appka by exposovala nejake api pro XD plugin, kterym by se dotazoval na postscriptname fontu podle fontname&style? Mozna jako lokalni http server. Prijde mi to teda trochu fragile
Nebo by XD ve svem vystupu vytvoril JSON file se seznamem fontu names&styles (muze byt asi v manifest jsonu kde je seznam artboardu) a appka by po tom co xd plugin dokonci svou praci ty fonty resolvnula a do toho json filu pridala i postscriptnames u fontu ktere nasla lokalne.

Idealni by bylo i automaticky uploadovat vsechny fonty pouzite v designu ktere nemame na serveru, jako to budem delat ted s version control pro sketch.

In GitLab by @nikitamironov on Mar 19, 2020, 12:01

Po precteni vsech komentaru nabizim tento postup:

XD plugin vytvari jak source, tak seznam pouzitych fontu.
Triggeruje appku pro nahrani techto dat na server.
Appka nejdriv zkousi resolvnout tyto fonty lokalne, takze hleda podle name/style.
Pokud nachazi, tak posila + posila mapku {[psn_nalezeneho_fontu]: [jeho_name, jeho_style]}.
Na serveru: pro nalezene fonty v octopus-konvertoru se resolvuje jejich spravne postscriptname, pro nenalezene se vytvari synteticky s flagem, ze je to synteticky psn.

Je to takhle pro vsichni ok?

In GitLab by @evzen on Mar 19, 2020, 12:03

ano :thumbsup:

In GitLab by @evzen on Mar 19, 2020, 12:05

Jak komplexni bude resolvovat lokalne font a predat tu informaci do pluginu

Urcite se obejdeme bez HTTP serveru. Resolvovat fonty podle font name neni nic sloziteho.

opendesigndev / octopus-specs