Dzięki za zaproszenie. Niestety, nie mam PocketBooka 614W tylko 624 i 650. W obydwu przypadkach załączam (oby skutecznie) zrzuty ekranu z reflow. Działanie trochę się różni, bo w PB 624 pokazują się na przykład pojedyncze literki, w 650 (inny firmware) jest całkiem normalny tekst bez względu na rozmiar czcionki. W PB 650 tekst dość czytelny również bez rozpływu po obróceniu na ekranie (landscape) i automagicznym obcięciu marginesów. Może wrzuć takiego PDFa kilkustronicowego, to obadamy takoż. Skalowanie czcionki możliwe w obu czytnikach w postaci szczypania ekranu.



PB 624



PB 650

Ja też nie mam 614-tki ale sprawdziłem jak się sprawy mają na moim PB Touch (622) i Touch Lux 2 (626). Ten pierwszy z najnowszym udostępnionym oprogramowaniem, czyli wersja 4.4 - ze strony PB wynika, że model 614 "jedzie" na tym samym oprogramowaniu, no i ekran też ma taki jak mója 622-ka. TL2 ma już oprogramowanie 5.2, a więc zbliżone do tego co oferuje PB Ultra (650) opisana przez Cyfranka.

Do testów użyłem:
1) "Lorema Ipsuma" udostępnionego przez athme,
2) EPUB Datasheet opublikowany przez Adobe,
3) Artykuł biofizyczny/biochemiczny opublikowany na stronach Uniwersytetu Illinoi - wygląda na część jakiegoś kursu - ot takie losowe szukanie; Link do PDF-a z artykułem.

A teraz pora na zrzuty ekranu - będę zamieszczał linki aby łatwiej było ogarnąć mój post.

1). Lorem Ipsum na PB 622:
a) Pełna strona,
b) Marginesy automatycznie przycięte,
c) Tryb reflow; wielkość czcionki dobrana tak aby ładniej było
d) Jak w punkcie b), ale poziomo,

2) Dokument od Adobe na PB 622 (wredny bo dwie kolumny tekstu, tytuł + podtytuł na dwie kolumny i do tego notki na marginesie):
a) Cała strona - automatyczne dopasowanie marginesów,
b) Tryb reflow,
c) Tak można dopasować marginesy ręcznie,
d) Tryb poziomy,

3) Artykuł naukowy na PB622 (wredny bo 2 kolumny + rysunki):
a) Widok całej strony,
b) Automatyczne dopasowanie marginesów - od biedy daje się czytać,
c) Widok kolumnowy - w trakcie czytania jedzie się kolumną do dołu, a potem jest przeskok do góry, na druga kolumnę,
d) Jak wyżej, ale czytnik poziomo,
e) Tryb reflow - grafika jest skalowana, ale PB nie radzi sobie z końcami linii (tj. nie skleja ich w akapity),

4) Tenże artykuł naukowy na PB626:
a) Cała strona - automatyczne dopasowanie marginesów,
b) Tryb kolumnowy - tu lepiej dopasował się do kolumny niż PB622,
c) Tryb reflow - lepiej niż na PB622 - linie się ładnie posklejały w akapity.

Tak to w skrócie wygląda - wydaje się, że ekran o większej rozdzielczości + nowsza wersja softu pozwalają osiągnąć nieco lepsze wyniki przy pracy z PDF-ami, czyli PB 626 nieznacznie wygrywa z PB622.

Aha, próbowałem coś kombinować z Calibre, ale wyniki konwersji są ... ekhem ... niezadowalające. Czytnik radzi sobie lepiej.

W pb 515 mini (4.4) to wychodzi że tu mam to samo co w 624/622 i co ciekawe powiększanie i pomniejszanie działa. Działa również na white-2009 (za to tu łapie zaciach przy dojściu do końca strony - nie chce przejść dalej)


Czyli pb ma 2 albo i więcej wersji ADE? ciekawe...
Jakoś słabo widzę żeby bezdotykowce dostały 5.x :/

A jest szansa sprawdzić wersję ADE? Bo zachowanie faktycznie wygląda ciut inaczej, ale nigdzie jakiś informacji o wersji nie namierzyłem. Jeszcze tylko dodam, że w PB 624 mam do wyboru otwieranie przy pomocy, AdobeViewer lub pdfviewer. Nie widzę między nimi żadnej różnicy. W PB 650 nie mam wyboru przeglądarki.
Co do firmware'u to też myślę, że nowy jest zrobiony z myślą o ekranach dotykowych i do bezdotykowych nie wejdzie.

No więc reflow pokazał figę. Na tym PDFie nie działa rozpływ. Natomiast w PB 650 w trybie landscape i obcięciu marginesów (bez rozpływu) czytelność OK.
Przetestowałem jeszcze obydwa pliki na TrekStorze Mini, poszło mu tak samo jak w przypadku PB 624.

No to mam podobnie z tym drugim plikiem jak cyfranek

co do wersji ADE to nie ma (z binarek wyszarpałem że u mnie mam rmsdk v9* a w 650 jest v10**)


*RMSDK_9_3_2_2012Oct30 (to samo w 614)
** RMSDK-10_0_2014-04-25

TrekStor ma inne oprogramowanie, dlatego chciałem przetestować.

No cóż, rzeczywiście są one wizualnie proste, sęk w tym co w środku siedzi. PDF jest formatem bardzo skomplikowanym do interpretacji (mam na myśli interpretację logiczną) - wszystko zależy od tego w jaki sposób został zapisany. Przykładowo: dany akapit możesz zapisać w PDF jako, powiedzmy, cały akapit, ale także jako zbiór linii, czy wręcz zbiór liter. Wyświetlenie tego przez interpreter PDF jest proste: rysujemy dany obiekt w zadanej pozycji i po sprawie. Jednak zrobienie reflow jest dużo bardziej skomplikowane bo trzeba zdecydować, że np. dane litery tworzą linie, a linie tworzą akapit. Innymi słowy - pisząc do PDF-a porzucamy informację o strukturze logicznej dokumentu, którą potem trzeba pracowicie odtworzyć.

Czemu ten konkretny dokument nie poddaje się trybowi reflow? Nie wiem i nie nie wiem też, czy chcę wiedzieć Wiem za to, że PDF nie został stworzony jako format do zapisu strumienia tekstu.

Tak przy okazji: ten drugi dokument wczytałem do MS Word-a - od biedy poradził sobie z interpretacją treści, ale tabliczkę mnożenia nieco rozjechał ... czy to ośmiesza moduł interpretacji PDF w MS Word? Ciekaw jestem jak inne aplikacje by sobie poradziły.

Jeśli Adobe Reader i/lub dowolny interpreter PDF-ów czyta to co wygenerował MS Word, nie rzuca błędami i wyświetla całość zgodnie z zamierzeniem, to chyba jest to zgodne ze specyfikacją PDF (a dokładniej mówiąc PDF-1.5, o czym mówi nagłówek pliku). Dotychczas nie napotkałem na problemy w tym względzie, aczkolwiek moje doświadczenie nie jest aż tak bogate. Jakieś konkretne przykłady?


Być może. Acrobata nie mam i nie będę miał - nie mój próg cenowy :p


O kurcze, widzę, że z grubej rury jedziemy

Zgadza się, wprowadziłem nieścisłości: nie ma w PDF akapitów, ale myślę, że da się takowe zasymulować przy pomocy pojedynczego obiektu tekstowego zawierającego kilka instrukcji rysowania ciągów znaków. Ale też, równie dobrze, ten sam tekst może być ciągiem niezależnych obiektów tekstowych, po jednej literce każdy - każdy ze swoimi własnymi atrybutami i własnym położeniem. Wydaje się, że w pierwszym wypadku wyciągnięcie tekstu (i jego zaszeregowanie jako linia tekstu, czy akapit) jest nieco łatwiejsze niż w drugim (gdzie trzeba zdecydować co z tymi osobnymi literkami zrobić). Jeszcze zabawniej się zrobi jeśli obiekty tekstowe rozrzucimy po całym dokumencie PDF, np. pierwszą linię tekstu zapiszemy na końcu dokumentu. Interpretacja (reflow) takiego PDF-a robi się nietrywialna. Prosty przykład: na wydruku widzisz 2^2 (dwa do potęgi drugiej) - w PDF-ie można to zapisać dwojako: albo używając operatora "text rise" aby przesunąć 2 do góry i operatora "text font size" aby pomniejszyć czcionkę, ale co stoi na przeszkodzie aby zapisać to jako dwa odrębne obiekty tekstowe, z własnymi pozycjami, atrybutami, itp. W pierwszym przypadku możesz wnioskować o ciągłości tekstu i stwierdzić, że ktoś po prostu użył indeksu górnego. W drugim - nie bardzo.

Odpowiadając więc na Twoje uwagi:


Zgadza się - tak jak też wyżej napisałem. Osobiście, poza "niepodzielnych" dodałbym jeszcze "niezależnych" - i właśnie na tym dokładnie polega problem.


Super - i co z nimi trzeba potem zrobić? Gdzie je wstawić? Jak zaszeregować?


Tzn. jakie konkretnie informacje? Nie mam w tej chwili żadnych narzędzi aby rozkodować ("zdeflatować") zawartość Twojego PDF-a aby dotrzeć do "gołego tekstu" PDF i się rozejrzeć.


No więc właśnie chyba ustaliliśmy (piszę "śmy" bo sam to poniekąd stwierdziłeś w punkcie 1)) że PDF w ogólności nie musi zawierać strumienia tekstu, a to ze względu na fakt, że tekst (a raczej glify tekst reprezentujące) możesz rysować (bo nie pisać) w dowolnej kolejności, ot choćby od końca do początku.


Zgadzam się w pełni, aczkolwiek podane przeze mnie przykłady, w tym przykład PDF-a naukowego, pokazują, że aż tak źle nie jest, co mnie osobiście dość mocno zaskoczyło. Dlatego twierdzę, że podane przez Ciebie przykłady, choć są banalne wizualnie, wcale nie muszą być banalne od strony wnętrza.


Jeśli o PDF-y chodzi, to nadal twierdzę, że najlepszy do tego jest tablet

Przez "wredny pdf" rozumiesz ten z tabliczką mnożenia? Jeśli tak, to reflow w nim po prostu nie działa - czytnik wyświetla PDF-a tak jakby wszedł w tryb "cała strona" i to bez dopasowania marginesów.

Co do Twoich przykładów to ściągnąłem sobie qpdf - takie narzędzie do przekształcania PDF-ów, co pozwoliło rozkompresować strumienie.

Lipsum.pdf jest prosty: jeden blok tekstu, ale np. używa operatora Td dla każdej linii co moim zdaniem powoduje "logiczne rozbicie" akapitu na poszczególne linie - ciekawi mnie czy użycie operatora ' zmieniłoby interpretację w trybie reflow.

Lipsum2.pdf jest bardziej pokręcony: spodziewałem się, że linie w tabliczce mnożenia są po prostu narysowane jako całość, a tu nie - wydaje się, że ta pionowa jest rysowana po kawałeczku, przy "drukowaniu" każdego wiersza tabliczki. Do tego przy rysowaniu każdego takiego małego odcinka stosowane są komendy, które zapamiętują i odtwarzają "stan graficzny". Nie wykluczam, że to jest powód, dla którego "reflow" "wymięka".

Za sugestią athame'a wydzieliłem dyskusje do nowego wątku bo się duży off-topic zrobił

Zaraz zobaczę co to za nowy PDF

A co do qpdf - to z opisu polecenia wnioskowałem, że on tylko rozpakował skompresowane strumienie, ale może rzeczywiście jeszcze grzebnął coś przy okazji ...

Tylko tak dla porządku dodam że calibre korzysta z propelera i jest to coś innego niż w ADE.

Wredny ma dorobione ogonki osobno , ale jeszcze może jedną sztuczkę sprawdzić
tj tekst sprowadzony do kodów np od 0x01 i podsunięty font z przedefinowaną kolejnością tych znaków by się dobrze wyświetlało.
Kto taki zrobi albo znajdzie?

Zrzuty ekranu z PB 626 Touch Lux 2 dla pliku "wredny.pdf", który rzeczywiście jest wredny

1) Cała strona - auto-dopasowanie marginesów
2) Reflow - podstrona 1
3) Reflow - podstrona 2
4) Reflow - podstrona 3

Przez "pdstrona" rozumiem to w jaki sposób czytnik podzielił stronę PDF na kawałki.

To co się rzuca w oczy, to wspomniana już separacja "ogonków" w polskich znakach diakrytycznych, oraz zła kolejność tekstu, np. 1-sza sekcja, 1-sza kolumna, po czym 2-ga sekcja, 1-sza kolumna, po czym znowu 1-sza sekcja, ale 2-ga kolumna.

Mam pytanie: co w ten sposób chcemy osiągnąć/wykazać? Że z pewnymi PDF-ami tryb reflow sobie nie radzi? Od początku wiadomo i nie jest to żadnym zaskoczeniem. Zaskoczeniem dla mnie było to, że reflow zadziałał sensownie z PDF-ami, o których sądziłem, że nie da rady.

Ciekawe, że po przeciągnięciu tego PDF-a przez qpdf (z opcjami --normalize-content=n --objest-streams=uncompress) dostałem np. takie coś:

"W październiku"

"Samsung użyła tej technologii"

Widać, że literki "ź" i "ż" są składane, natomiast "ł" rzeczywiście jest bezpośrednim kodem znaku. Dziwne to.

Swoją drogą to ciekawe jak dokładnie PocketBook realizuje ten reflow ...

Ooops, przepraszam - już poprawione.


Już powinno być widać na poprawionych linkach


Zaraz, zaraz, czy my mówimy o tym samym PDF-ie? W poprzednim poście (i jeszcze poprzedniejszym) pokazałem Ci co wychodzi po przepuszczeniu tego pliku przez qpdf. Mogę uwierzyć, że qpdf coś sobie pogmerał i "znormalizował" zmieniając strukturę PDF-a, choć jedyne co kazałem mu zrobić to rozkompresować strumienie, ale w to, że podmienił czcionki to wydaje mi się mało prawdopodobne. Otóż w tym PDF-ie widzę dwie osadzone czcionki Type 1C o nazwie Nimbus Roman no 9 L Medium i Regular. Biorąc pod uwagę, że dokument został wygenerowany przy pomocy pdfTeX-a, to przestają mnie dziwić triki z ogonkami ...

Pytanie dodatkowe: czy możesz wygenerować taki sam PDF ale z czcionkami TT a nie Type 1?