PDFlibPas ritar japansk och kinesisk text nedåt över sidan. SetVerticalWritingMode slår på vertikalt skrivande, vanliga DrawText-anrop löper sedan nedåt, och GetVerticalWritingMode rapporterar det aktuella tillståndet. Innan detta fanns betydde vertikal text att placera varje tecken för hand och hoppas att avståndet såg rätt ut
Vertikal text är inte horisontell text roterad nittio grader. Tecknen förblir upprätta, steget löper nedåt i stället för på tvären, och ett antal tecken byter form helt — vilket är den del som skiljer ett dokument som läses naturligt från ett som en japansk läsare omedelbart känner igen som maskintillverkat
Vad som ändras inuti PDF:en
Text ritad på detta sätt går genom ett Type0-teckensnitt i vertikalt skrivläge som bär typsnittets egna vertikala mått. Det betyder något i två riktningar. En läsare stepper fram varje tecken med det avstånd dess designer avsåg i stället för med ett enhetligt steg, så kolumnen har den rytm typsnittet ritades för. Och att kopiera ut texten returnerar de ursprungliga tecknen, eftersom den vertikala körningen fortfarande är riktig text med en riktig mappning i stället för en sekvens av positionerade glyfer
Ett typsnitt som inte bär några egna vertikala mått stepper ett em per tecken, vilket är vad en läsare skulle göra med standarden. Den reserven är värd att känna till eftersom det är skillnaden du kommer se när ett dokument renderas korrekt med ett riktigt CJK-typsnitt och ser mekaniskt avstånd med ett latinskt typsnitt som råkar innehålla lite kana
var
Lib: TPDFlib;
H: Double;
begin
Lib := TPDFlib.Create;
try
Lib.SetOrigin(1);
Lib.AddTrueTypeFont('MS Mincho', 1); // 1 = embed the face
Lib.SetTextSize(12);
Lib.SetVerticalWritingMode(1); // ordinary DrawText now runs down
H := Lib.GetVerticalTextHeight('MS Mincho', 12, '第三章 保守点検');
Lib.DrawText(480, 72, '第三章 保守点検');
Lib.SetVerticalWritingMode(0); // back to horizontal
Lib.DrawText(72, 72 + H, 'Chapter 3');
Lib.SaveToFile('manual-ja.pdf');
finally
Lib.Free;
end;
end;
Varför ser parenteser fel ut i vertikal text?
Eftersom en parentes har två former och bara en av dem hör hemma i en kolumn. Parenteser, det långa vokaltecknet och de små kana ritas annorlunda när text löper nedåt över sidan — en parentes roterar för att sitta längs kolumnen i stället för att ligga på tvären, och det långa vokaltecknet blir ett vertikalt streck. Rita de horisontella formerna i en vertikal kolumn och var och en av dem ligger på sidan
PDFlibPas tar formerna från typsnittets egen vertikala feature, så varje typsnitt tillhandahåller vad dess designer ritade i stället för en substitution gissad från tecknet. Den skillnaden betyder något för korrekthet: en gissad substitutionstabell är rätt för de vanliga fallen och fel för de typsnitt som behandlar ett tecken annorlunda, och ett typsnitt som inte namnger några vertikala former ritas exakt som förut i stället för att tvingas genom en tabell det aldrig bad om
GetVerticalTextHeight mäter de former som faktiskt kommer att ritas, så en kolumn vars tecken byter form mäts fortfarande korrekt. Att mäta de horisontella formerna och rita de vertikala är den klassiska källan till kolumner som överlöper sin ruta med några tecken
Rita en körning utan att ändra läget
DrawVerticalText ritar en enda körning vertikalt, tar position, teckensnittsnamn, storlek och text, och lämnar skrivläget orört. Använd det för det vertikala undantaget inuti ett horisontellt dokument — en ryggetikett, en stämpel, en ensam kolumn med namn — där att slå på och av ett globalt läge runt varje anrop är mer tillstånd än uppgiften förtjänar
De horisontella och vertikala formerna av ett typsnitt hålls isär internt, så en sida kan bära båda utan att någon av dem stör den andra. Det är vad som gör en blandad sida praktisk: en japansk bok sida med vertikal brödtext och horisontella löpande sidhuvuden, eller ett kinesiskt certifikat med en vertikal titel över horisontella detaljrader
// One vertical run inside an otherwise horizontal page
Lib.DrawVerticalText(520, 96, 'MS Mincho', 14, '保守点検記録');
// The horizontal text around it is unaffected
Lib.DrawText(72, 96, 'Maintenance inspection record');
Att få teckensnittet rätt innan något annat
Vertikal text beror helt av typsnittet. Ett CJK-teckensnitt med riktiga vertikala mått och en vertikal feature producerar korrekt utdata utan vidare arbete; ett typsnitt utan dem producerar uppratta tecken som stepper ett em i taget och inga formbyten alls. Om vertikal text ser subtilt fel ut, undersök teckensnittet innan du undersöker koden
Inbäddning följer de vanliga reglerna och de vanliga kostnaderna. Ett fullständigt CJK-typsnitt är stort, så delmängdskapande är inte valfritt för dokument som ska någonstans — noterna om PDF-filstorleksoptimering och teckensnittsdelmängder täcker vad du kan förvänta dig, och genomgången av inbäddning av saknade teckensnitt i en befintlig PDF täcker reparationsfallet där ett vertikalt dokument anländer utan sina teckensnitt
Var vertikal text fortfarande behöver ett layoutbeslut av dig
Kolumnordning. Japansk vertikal text löper höger till vänster per kolumn, så en tvåkolumnssida börjar vid högerkanten, och ingen skrivlägesinställning kan härleda det från texten. Detsamma gäller sidordning i ett dokument som läses höger till vänster som helhet, och var furigana, fotnoter och figurtexter sitter
Vad biblioteket garanterar är att varje körning sätts korrekt: rätta former, rätta steg, extraherbar text. Var körningarna hamnar på sidan är ett layoutproblem, och för dokument sammansatta från data är genomgången av textsökning och sidelementsuppräkning användbar för att i efterhand verifiera att det som landade på sidan var vad du avsåg
PDFlibPas är ett inbyggt Pascal PDF-bibliotek för Delphi, C++Builder och Lazarus, och vertikalt CJK-skrivande är del av rit-API:et i stället för ett tillägg — se PDFlibPas produktsida för text- och teckensnittsfunktionslistan