Typed rich-text JSON line height
forms.fill akceptuje opcjonalnych członków lineHeightKind i lineHeight na każdym oryginalnym itemie richTextRuns, używając rzeczywistego layoutu akapitu i fizycznych linii dostarczonego fontu
{
"schemaVersion": 1,
"type": "forms.fill",
"fields": [{
"name": "Input",
"richTextRuns": [{
"text": "First
Second",
"fontSize": 10,
"lineHeightKind": "number",
"lineHeight": 2
}]
}]
}| Rodzaj | Wartość i zachowanie |
|---|---|
| legacy | Domyślny, gdy żaden członek nie jest dostarczony, zachowując istniejący layout akapitu |
| normal | Jawny layout normal używający metryk dostarczonego fontu i natywnego odstępu linii |
| number | Nieujemny czynnik bez jednostki mnożony przez fontSize tego runa |
| points | Nieujemna absolutna wysokość punktowa |
| percent | Procent natychmiast przeliczany z fontSize tego runa i przechowywany jako punkty |
| em | Czynnik natychmiast przeliczany z fontSize tego runa i przechowywany jako punkty |
Numeryczna lineHeight bez lineHeightKind wybiera number; każdy numeryczny rodzaj wymaga wartości, podczas gdy legacy i normal akceptują wartość nieobecną albo zero
Wartości muszą być skończone i między zerem a milionem; ich obliczona wysokość punktowa też musi się mieścić w tej granicy, a nieznane nazwy rodzajów albo niepoprawne typy zawodzą przed ładowaniem fontów
Zero jest wspierane i może dać nachodzące linie bazowe; rzeczywiste ascendery i descendery kroju określają ujemne pół-interlinie i unię boksu podpory akapitu i uczestniczących boksów runów
Każdy JSON run to oryginalny item typowany, a nie element CSS; percent i em nie wprowadzają dziedziczenia między obiektami JSON runów
Pierwszy run dostarcza styl metryczny akapitu; pusty pierwszy run może wnieść większy albo inaczej stylizowany boks rodzica, a odrębna przygotowana sekwencja dopuszcza swój rzeczywisty font bez zastępowania autorskich runów
IsParagraphStrut nie jest publicznym członkiem JSON; wygenerowane runy wyłącznie metryczne liczą się do narastającego budżetu runów operacji, a każdy załadowany krój metryczny liczy się do zagregowanych bajtów fontów
Callback otrzymuje rzeczywiste żądania skonfigurowanej rodziny i stylu, łącznie z krojem rodzica nie malującym tekstu; istniejące zadania plikowe Windows oparte na ścieżkach używają tego samego parsera typowanego i planisty dostarczonych fontów
Zapisane V zachowuje tekst logiczny, RV zapisuje obliczony profil akapitu, a AP zachowuje oryginalną precyzję koloru i rozmiaru fontu
Niezmienione operacje w pełni rich zachowują dokładne zacommitowane bajty PDF, łącznie z poprawnymi semantycznymi no-opami tylko do odczytu; zmienione style read-only, awarie uwierzytelnienia AES i chronione pola podpisów zachowują istniejące polityki
Błędy callbacków, anulowanie i awarie budżetu publikacji zachowują poprzedni kontekst; zadania plikowe też zachowują poprzedni cel przy publikacji atomowej
Ujście callbacka mogło już zaakceptować bajty kandydata PDF, gdy późniejszy callback zawiedzie; żywy kontekst commituje dopiero po sukcesie wymaganych callbacków i finalnych sprawdzeń anulowania
Wersjonowane layouty operacji C i callbacka fontu są niezmienione; zdolności reklamują rzeczywiste rodzaje i granice lineHeight wewnątrz profilu typowanego wypełniania