Kroje liter, konwersja

0

Czy ktoś z Was ma jakieś doświadczenie z PostScriptem, pdf-em, krojami (liter), itp.?

W pdf-ach mogą osadzone kroje. Niektóre są stosunkowo proste (t1, ttf).
Ale mogą być też bardziej zakręcone (CFF, CID).
Potrzebuję w locie konwertować te CFF i CID na t1.
Na GitHubie jest biblioteka, która konwertuje CFF na t1:
https://github.com/kohler/lcdf-typetools
I to działa.
Korespondowałem z jej autorem w sprawie CID i pożyczył mi powodzenia ;-).
Pisanie od zera konwertera - to znowu miesiące pracy.

Jest taka biblioteka:
https://www.freetype.org

Ale ciężko się zorientować, czy ona obsługuje te CID-y.
Może ktoś nad tym pracował? i coś powie?
Albo ktoś rozgryzał kod GhostScripta?

0

A w sumie po co ci taka konwersja. Jak napisano w komentarzu, to bardzo specjalizowana sprawa, to raczej ciężko znaleźć tu kogoś kto bawił się w takie rzeczy. Z kolei z tego że NIE ma rozwiązania typu konwerter(czyli rzecz dość prosta) to zastanawia czy to w ogóle na sens.

0

Wiesz - ci od tej biblioteki:
https://www.freetype.org
napisali tak:
Counting the above products only, you get more than a billion devices that contain FreeType.

Więc założyłem, że może w Polsce jest ktoś, kto się tym zajmował :-)

Czy to jest potrzebne? - za każdym razem kiedy otwierasz pdf-a - oprogramowanie robi takie konwersje :-).

Na początku był PostScript :-). To język programowania, w oparciu o który pracują wszystkie programy graficzne, które wymieniają ze sobą pliki eps lub ps (więc liczba odbiorców takiego oprogramowania jest niemała).
PostScript - to taki specyficzny język, który pracuje na stosie wykorzystując notację ONP.
I potem powstał pdf. Pdf - to nie jest język programowania. To specyficzny sposób zapisu danych wykorzystujący cechy języka PostScript.
Tzn. jak już napisałem interpreter PostScriptu, to mogłem napisać w PostScripcie program, który wykonując się w tym interpreterze "wciąga" pdf-y.
Po co mi to? Otóż drukarnie przestawiają się z ps-ów, na pdf-y.
A w drukarniach jedną z podstawowych operacji przed drukiem jest impozycja, czyli montaż. Np. z liniowego pdf-a A4 (kolejno numerowane strony) potrzebujesz montaż stron na A3 - 1-4, 2-3, itd.

Do tego wykorzystywane jest drogie specjalistyczne oprogramowanie.
Środowisko twórców tego oprogramowania jest hermetyczne - czysta komercja :-), a rynek - to wszystkie drukarnie.
Ale - jest grupa, która stworzył alternatywny GhostScript (chociaż on - póki co - nie robi impozycji). Kod źródłowy jest - ale na licencji GPL.
Być może jest ktoś w Polsce, kto brał udział w tych pracach?

Jasne - jak będzie trzeba - to napiszę, ale jakby ktoś jeszcze siedział nad podobnymi problemami - to warto byłoby móc porozmawiać, bo dokumentacja jest napisana mętnie i czasem nie ma z kim przedyskutować wątpliwości.

0

To co piszesz jest ciekawe, ale wciąż nie rozumiem konkretnie co chcesz osiągnąć. Przecież konwersja pdf-ps to nie problem. Zmiana kolejności stron w ps też chyba nie...

0

Ten pdf - to nie jest trywialny plik.
Z jednej strony - to nie jest język. Ale z drugiej, to nie jest tylko ciąg bajtów (jak np. w bitmapie). Jest tam pewna logika, którą trzeba "obliczyć".
W PostScripcie są tzw słowniki. To jest tak jakbyś miał przestrzeń nazw.
Słowa zdefiniowane w słowniku, są widziane tylko w nim.
Dla zobrazowania wkleję kawałek (z nagłówka) kroju t1 (% rozpoczyna komentarz)

/FontInfo                                   %deklaracja zmiennej
     12 dict begin                          %12 elementów -> tworzy słownik -> begin ->otwiera słownik
          /ItalicAngle -15.0 def          %zmienna ItalicAngle jest zdefiniowana na -15
          /UnderlinePosition -118 def    %kolejne zmienne sa dodawane do słownika
          ...
          ...
    def                                %ten def zamyka ten słownik i definiuje zmienną FontInfo

Od tej chwili masz słownik (przestrzeń nazw), która nazywa się FontInfo. I w niej masz zmienne (ItalicAngle, itd.).

W pliku pdf masz obiekty, które są słownikami (mogą być jeszcze tablicami), ale załóżmy są same słowniki.

Strona to jest słownik. W nim jest wpis /Resource - to jest kolejny słownik. W nim masz np. trzy kroje /F0, /F1, /F2.
I masz gdzie indziej w pliku słownik /F1, a w nim masz zdefiniowany ten krój. Załóżmy, że to Arial.

I teraz masz drugą stronę. I tam masz też /Resource (każda strona ma swoje "zasoby").
I w tym /Resource też masz /F1, F2, itd. Ale ten F1 może już być Times. Rozumiesz?

I teraz chcesz to połączyć w jedną stronę. Co musisz zrobić? Połączyć słowniki, żeby powstał jeden /Resource dla nowej strony. Ale tu kicha - bo masz dwa /F1, które znaczą co innego.
Musisz to rozebrać na atomy, dodać unikalne identyfikatory dla każdej strony, żeby po połączeniu to się nie pomieszało.
To w kwestii łączenia stron (co jest właśnie meritum impozycji).

Teraz jak się to połączy, to chciałoby się zobaczyć co wyszło.
Więc lecisz po kolei to co jest w słowniku /Content. Tam są wpisy w stylu:
10 20 moveto
100 200 lineto
stroke
(to znaczy narysuj linię od punktu 10 20 do punktu 100 200)

i trafiasz np. na /GS 0
co oznacza otwórz "stan graficzny numer 0".
Zaglądasz do tego GS0, tam jest /F0
Zaglądasz do F0 - tam jest np. wpis /CIDFontType0C co oznacza, że dalej polecą binarne dane opisujące krój typu CID. I dalej masz (test) tj.
Nawiasy - to tak dla zmyłki :-) - oznaczają w PostScripcie to, co w normalnych językach cudzysłowy :-).
A tj - to operator wyświetlania tekstu
Czyli masz do wyświetlenia napis "test" krojem, który jest zakodowany binarnie po tym /CIDFontType0C.
Żeby to wyświetlić, musisz odkodować ten ciąg bajtów i zamienić go w jakiś format zrozumiały dla platformy, na której działasz (lub po prostu na ciąg odcinków i krzywych beziera).
Problem z CID key fonts polega głównie na zagmatwanym sposobie przekodowywania glyphów (glyph - to wektorowy ciąg odcinków i krzywych beziera opisujący jeden znak lub fragment znaku. Np. litera ż może się składac z dwóch glyphów). Musisz odkodować, które glyphy są Ci potrzebne i zbudować znak, który potem wyświetlisz. Nie ma procedur systemowych, które wprost ten ciąg binarny (po słowne /CIDFontType0C) Ci wyświetlą.

Ja napisałem sobie interpreter, który może pracować w dwóch trybach.
W trybie "normalnym" wszystko się dzieje w tle i użytkownik widzi efekt.

Ale możesz przejść (jak w debuggerze) do pracy krokowej.
Wtedy masz na ekranie stos i te wszystkie słowniki. I możesz krokowo to wykonywać. Widzisz jak w kolejnych krokach ten plik pdf jest wciągany i rozbierany na atomy. No i dochodzisz do tego miejsca z krojem i - stop :-). Dalej nie pójdziemy, musisz rozebrać ten binarny ciąg :-).

To tak w skrócie :-).

1

W sumie miałem na myśli "co chcesz zrobić w sensie logicznym?", ale teraz rozumiem że po prostu masz już duży system który rozwijasz, to trochę zmienia postać rzeczy. Moje doświadczenie w sumie sprowadzało się zawsze do tego że wrzucałem pliki do a2ps i wszystko działało i wychodziłem z założenia że nawet jeśli są jakieś błędne przypadku lepiej już latać istniejący projekt, tym bardziej open source.

Ten problem nie wydaje się tak bardzo rażący bo wystarczyłoby każdy klucz w słowniku opatrzyć prefiksem zależnie od pliku z którego pochodzi. No ale ta konwersja to coś trudniejszego za pewne.

0

A w drukarniach jedną z podstawowych operacji przed drukiem jest impozycja, czyli montaż. Np. z liniowego pdf-a A4 (kolejno numerowane strony) potrzebujesz montaż stron na A3 - 1-4, 2-3, itd.

Do tego wykorzystywane jest drogie specjalistyczne oprogramowanie.

Do tego gdy potrzebowałem to z powodzeniem wykorzystywałem darmowe specjalistyczne oprogramowanie jakim jest pstops ;-)

1 użytkowników online, w tym zalogowanych: 0, gości: 1