Testversie Google Chrome kan in pdf's twee pagina's naast elkaar laten zien

De Canary-versie van Chrome heeft de optie gekregen om in pdf's twee pagina's naast elkaar te tonen. Diverse pdf-lezers voor desktop kunnen dat al langer, maar de browser ondersteunt dat nu nog niet.

Google Chrome Canary: Two-up View
Screenshot: Techdows

De functie heet Two-up View, meldt Techdows. Het is een optie die via de flags-functie in te schakelen is, door in Chrome op deze link te klikken. Vervolgens moeten gebruikers instellen dat Chrome de pdf-bestanden opent en niet downloadt, waarna de browser een knop erbij krijgt om pdf's te tonen met twee pagina's naast elkaar.

Techdows merkt op dat de klassieke versie van Edge, dus niet de nieuwe op basis van Googles Chromium-project, de functie al ondersteunde met de snelkoppeling F8. Het is onbekend of de zoekgigant bij de release ook een snelkoppeling zal toewijzen aan de functie. Ook Acrobat Reader DC voor desktops ondersteunt het tonen van twee pdf-pagina's naast elkaar.

Functies die in de Canary-versie zitten, komen vaak op een later moment in de stabiele versie van de browser. Google heeft nog niets bekendgemaakt over of dat gebeurt en zo ja, wanneer dat zal zijn. De functie zit in Canary 82.0.4084.0 of later. De stabiele versie zit nu op versie 80.

Door Arnoud Wokke

Redacteur Tweakers

12-03-2020 • 14:13

38

Reacties (38)

38
37
19
2
0
9
Wijzig sortering
Het is soms handig om twee pagina's uit één document naast elkaar te hebben, vooral op brede schermen of voor documenten die oorspronkelijk ontworpen zijn als fysiek boekje. Met twee aparte vensters is het niet makkelijk om twee pagina's tegelijkertijd omhoog of omlaag te scrollen.

Sommige reacties hier zijn een beetje spottend, alsof het makkelijk is om zoiets te maken. Ik heb van heel dichtbij gezien hoe ingewikkeld het eigenlijk kan zijn.

Firefox heeft deze functie twee jaar geleden gekregen (met dank aan een vrijwilliger bij PDF.js), en er gingen vele weken overheen voordat ik het goedkeurde: https://github.com/mozilla/pdf.js/pull/9208

Vragen als:
- Eerste pagina apart (titelblad), of toch samen met de tweede pagina?
- Wat als pagina's niet dezelfde grootte, vorm of oriëntatie hebben?
- Werkt inzoomen nog wel goed?
- Hoe kun je deze functie beschikbaar maken in de gebruikersinterface zodat iedereen het direct snapt?
- Wat moet het gedrag zijn van sneltoetsen?
- Als je door het document heen bladert, moet dat met twee pagina's tegelijk?
- Waarom eigenlijk beperken tot twee pagina's? Waarom niet meer naast elkaar?

Het resultaat kan je in Firefox zien door een PDF te openen en het menu te openen in de rechter bovenhoek, bij spreads/scrolling. Als je Firefox niet hebt, kan je het ook in de online demo van PDF.js uitproberen: https://mozilla.github.io/pdf.js/web/viewer.html
Ik vind dat PDF viewers in een browser altijd maar weinig toevoegen aan functionaliteit. Twee pagina’s naast elkaar... wow.

Net als desktop viewers zoals Adobe DC. Behalve omzetten naar docx en OCR kan Preview eigenlijk alles wel. macOS heeft ondersteuning voor PDF ingebouwd, systemwide. Heeft Windows dat niet eigenlijk?
Ik vind het anders erg handig dat ik geen apart programma hoef op te starten, en het PDFje gewoon als een webpagina tussen mijn tabbladen en bookmarks kan zetten. Het is bijvoorbeeld toch net wat makkelijker om de datasheets van electronica onderdelen naast de tabbladen van de winkelpagina's te hebben, dan dat ik ze in aparte programma's steeds bij elkaar moet zoeken.

[Reactie gewijzigd door ThePendulum op 22 juli 2024 18:14]

Ik vind het anders erg handig dat ik geen apart programma hoef op te starten, en het PDFje gewoon als een webpagina tussen mijn tabbladen en bookmarks kan zetten.
Het zou nog mooier zijn als browser en applicatie netjes integreren, zodat ieder zich kan specialiseren. Je kan onmogelijk support voor alle denkbare fileformaten in een browser stoppen. Als je dat probeert kom je al snel met ondermaatse en halfbakken implementaties te zitten. Zie hier het voorbeeld van twee pagina's tegelijk laten zien. Dat is toch wel zo'n basale functie dat ik me af vraag welke functionaliteit er nog meer mist.
Je kan beter met een plugin-systeem werken waarbij de browser het zware werk kan uitbesteden aan andere applicaties, zoals ooit heel gewoon was.
Ik herinner me de werkelijkheid daarvan toch wel iets anders... de ene website gebruikt Flash, de andere Java, dan weer SilverLight, die moet je installeren en dan voortdurend updaten, om er vervolgens achter te komen dat de ene website alleen werkt met een oude versie en de andere alleen met een nieuwe versie. Wat je dan uiteindelijk aan de praat kreeg deed vaak eveneens onder voor het volledige programma. De wat minder technisch aangelegde leden van de familie haalden zich zo ook makkelijk heel wat virussen op de hals.

Zowel als web ontwikkelaar als gebruiker ben ik blij dat browsers tegenwoordig in ieder geval een schappelijke ondersteuning voor video, audio en grafische elementen geïntegreerd hebben. Ik verwacht van een browser geen volledige suite voor ieder bestandsformaat, maar een basisweergave van een of twee standaarden binnen ieder type. Ik beschouw PDF daarin min of meer als de PNG van de documenten.

Als ik moet gaan nadenken welke functionaliteit ik nog mis, heeft het zijn doel al ruimschoots bereikt. Het is handig dat je nu twee documenten naast elkaar kunt zetten, maar dat heb je niet nodig om even de afvalkalender van je gemeente te bekijken, en zie ik niet als kritiek onderdeel van de implementatie.

[Reactie gewijzigd door ThePendulum op 22 juli 2024 18:14]

Volgens mij is jouw beleving behoorlijk verpest door Internet Explorer/Windows.
Mijn grote voorbeeld is hoe Konqueror het 10 jaar geleden deed (en nog steeds, maar de kwaliteit is niet wat het geweest is).
Konqueror doet niks zelf en laat alles aan plugins over. Al die plugins zijn gelijkwaardig, het maakt weinig uit of je HTML, een .png of een Word-document bekijkt. Konqueror kijkt wat er nodig is, zoekt tussen z'n plugins naar de juiste applicatie en start die. KDE is zo opgezet dat alle KDE software direct als plugin gebruikt kan worden. "plugin" geeft misschien het verkeerde gevoel omdat plugins vaak nogal beperkt zijn. Het gaat hier echter om volledige applicaties die direct worden geintegreerd. Door de opzet van KDE kun je zo'n applicatie direct als plugin gebruiken, los van de GUI van die applicaties.
Het is niet heel anders dan wat Microsoft doet met MS-Office waarbij je een Excel-bestand in je Word-bestand kan embedden, maar dan beter opgezet.
Ik herinner me de werkelijkheid daarvan toch wel iets anders... de ene website gebruikt Flash, de andere Java, dan weer SilverLight, die moet je installeren en dan voortdurend updaten, om er
Ik vind het niet zo'n beste voorbeelden want dit zijn juist protocollen die je eigenlijk niet buiten je browser gebruikt. (Java tegenwoordig wel, maar toen niet).
vervolgens achter te komen dat de ene website alleen werkt met een oude versie en de andere alleen met een nieuwe versie.
Dat ligt aan de instabiliteit van die bestandformaten, dat heeft niks te maken met of de browser het doet of niet. Juist als je het aan de browsers overlaat is de kans groot dat er verschillen tussen de browsers gaan zijn, zeker bij complexe formaten zoals flash.
Zowel als web ontwikkelaar als gebruiker ben ik blij dat browsers tegenwoordig in ieder geval een schappelijke ondersteuning voor video, audio en grafische elementen geïntegreerd hebben. Ik verwacht van een browser geen volledige suite voor ieder bestandsformaat, maar een basisweergave van een of twee standaarden binnen ieder type.
Juist zo'n basisweergave is gevaarlijk. Dat is namelijk waarschijnlijk maar een minimaal aftreksel van de volledige applicatie waarbij het maar de vraag is of de programmeurs net zo veel moeite hebben genomen om over de veiligheid na te denken. Dingen die niet helemaal geimplementeerd zijn bieden vaak een aangrijpingspunt om rotzooi mee uit te halen.
Konqueror doet niks zelf en laat alles aan plugins over. Al die plugins zijn gelijkwaardig, het maakt weinig uit of je HTML, een .png of een Word-document bekijkt. Konqueror kijkt wat er nodig is, zoekt tussen z'n plugins naar de juiste applicatie en start die.
Dus je hebt een schil (browser) in een schil (OS)? Dat klinkt omslachtig.
In mijn optiek moet een browser gewoon doen wat ie moet doen: webpagina's weergeven, en verder niets.
Een PDF viewer in de browser is handig, zal ik niet ontkennen, maar er zijn grenzen qua contenttypes, denk ik.. het landschap is behoorlijk divers wat dat betreft.
Nee, zo moet je het niet zien, Konqueror is het deel van het OS dat de schil is voor allerlei viewers.
Laat het idee los van een browser voor het web, een tekstverwerker om documenten te bekijken, een viewer voor PDF, een image viewer voor .jpg. Waarom zou je voor ieder type bestand een apart programma hebben? Zorg voor 1 goede interface die verschillende backends kan gebruiken om data te laten zien.
Dan heb je Konqueror.

Echt uniek is het idee niet hoor. Volgens mij is het ook de gedachte achter Explorer, in de tijd dat Windows Explorer en Internet Explorer hetzelfde waren. Maar daar was het idee veel minder goed uitgewerkt.

Ik heb het hier alleen over het bekijken van bestanden. Zodra je ze gaat bewerken dan heeft het zin om een gespecialiseerde GUI te gebruiken. Het bewerken van een stuk tekst is totaal anders dan het tekenen van het plaatje. Het bekijken is echter vrijwel hetzelfde. Je zet het op het scherm en je kijkt er met je ogen naar en in vrijwel alle gevallen heb je alleen wat simpele controls om te zoomen of naar de volgende onderdeel te gaan.


Je OS levert ook de knopjes en andere elementen waar je GUI uit is opgebouwd.
Hetzelfde idee als dat je PSD bestanden op Mac kunt bekijken in finder, zonder Photoshop op te starten?
Ik weet niet genoeg van Mac om daar iets over te kunnen zeggen.
Het gaat me er niet om dat er een "verkenner" is waarmee je /sommige/ soorten bestanden kan previewen.
Het gaat me er om dat er een framework is om applicaties samen te laten werken, bv voor het previewen van bestanden, dat eenvoudig uitbreidbaar is met nieuwe applicaties, zonder dat van te voren vast staat welke applicaties of welke bestandsformaten er gebruikt worden.

Dat is overigens niet tot het previewen van bestanden beperkt maar kan ook op andere gebieden werken.

Zo zijn er systemen (zoals het eerder genoemde KDE) dat "virtual filesystems" faciliteert.
Het idee is dat het niet uit moet maken waar een bestand staat. Of het nu op een traditionele hardeschijf is, op een netwerkshare, of een ftp-server of op een web-server, al dan niet over http, https, of met inloggen met een username of 2FA, moet niet uitmaken voor applicaties.

Applicaties willen gewoon een file krijgen en misschien ook weer opslaan, het OS moet verder maar uitzoeken hoe dat moet. Applicaties met ingebouwde upload of download functionaliteit pakken het verkeerd aan (uiteraard met uitzondering van de applicaties/plugins die voor deze functionaliteit zorgen. Het is prima dat Word weet hoe je met .docx moet omgaan, maar andere applicaties moeten dat niet gaan dupliceren en gewoon gebruik maken van Word als ze iets met .docx willen).

Dit zijn geen vernieuwende ideeën. Ieder OS modern werkt min of meer volgens dit principe. Het verschil zit vooral in de uitvoering en het gemak waarmee applicatieprogrammeurs er mee om kunnen gaan. Juist daarom is KDE voor mij het grote voorbeeld want dat is zo opgezet dat je als applicatieprogrammeur niks extra hoeft te doen om te weten om er gebruik van te maken. Als je lui bent en niet meer dan het minimale doet dan krijg je al die functionaliteit er bij. Iedere KDE applicatie kan je bv een URL geven in plaats van een gewone filename en het systeem zorgt wel dat de data wordt binnengehaald (en daarna eventueel weer wordt geupload), zonder dat de applicatieprogrammeur daar iets voor hoeft te doen.
Dat plugin systeem was juist dramatisch. Kreeg je elke dag update popups, Adobe Acrobat was enorm bloated, dus als je per ongelijk een PDFje aanklikte kon je 20 seconde wachten. En daarnaast had je continu allemaal lekken in Adobe, de mediaplayers, Flash, Java etc. De meeste bouwers van plugins waren geen experts op het gebied van veiligheid.

De tijd dat je computer vol spyware stond doordat je naar een verkeerde site surfte ligt gelukkig alweer een tijd achter ons. Laten we dat vooral zo houden.
[quote]
Dat plugin systeem was juist dramatisch. Kreeg je elke dag update popups, Adobe Acrobat was enorm bloated, dus als je per ongelijk een PDFje aanklikte kon je 20 seconde wachten.
[quote]
Updates zijn nu eenmaal een drama onder Windows, dat heeft niks met browsers of plugins te maken.
Dat de software van Adobe langzaam is zegt ook niks, gebruik dan wat anders, er zijn zat andere PDF-lezers die wel snel zijn.
En daarnaast had je continu allemaal lekken in Adobe, de mediaplayers, Flash, Java etc. De meeste bouwers van plugins waren geen experts op het gebied van veiligheid.
De wereld is sindsdien ook wel een beetje veranderd. Je hebt wel een punt dat de meeste software-schrijvers niet zo best zijn in beveiliging, maar al die mensen die nodig zijn om al die fileformaten in browser in te bouwen kunnen ook niet allemaal beveiligingsexperts zijn. Je browser en OS zouden moeten zorgen dat die software in een veilige container wordt gedraaid, dat is met de techniek van tegenwoordig prima mogelijk.
Dat deden ze toch, totdat browsermakers al die functionaliteit (herinner de adobe pdf plugin) eruitsloopten ten voorkeur van de web plugins zoals chrome/edge nu ondersteunen.
Mee eens hoor dat openen in de browser makkelijk werkt. Maar ik zou denken dat in 2020 een browser toch al meer zou moeten kunnen met een pdf dan twee pagina’s naast elkaar zetten. Vergelijkbaar met Preview dus, of Adobe DC, zou je toch wellicht wel tekst of een handtekening direct in de browser moeten kunnen toevoegen?

Zonder plugins dus, hoe minder plugins hoe beter wat mij betreft.

[Reactie gewijzigd door SMRF op 22 juli 2024 18:14]

Er is wel degelijk een voordeel mits de browser niet het PDF bestand blijft bewaren. Denk aan medische applicaties die door medewerkers met een laptop zelf te benaderen zijn en in de 'Downloaded' folder blijven staan. Veel minder veilig dan een PDF viewer.
volledig mee eens! En de browser krijgt automatisch updates. die Acrobat Reader niet... en is al veel meer het slachtoffer geweest van lekken.
Ja, via de Edge browser dus, volgens mij.
Maar dat is niet door het hele systeem.
Hoe bedoel je, 'door het hele systeem'?
Je kunt overal vanuit macos een pdf maken, vanuit allerlei bronnen. In bestandsmenu’s, tijdens afdruktaken. En Preview is een capabele pdf viewer en editor.
Je kunt overal in Windows naar PDF printen in plaats van een gewone printer en je kunt een PDF altijd in Edge bekijken.
Maar het aanpassen van PDF’s kan nog niet zonder extra tools zoals Adobe DC toch? Ik gebruik Preview al jaren voor snel plaatsen van een handtekening. Tegenwoordig doe je dat direct vanuit Het mailprogramma van macOS en krijg je het voorstel om te ondertekenen via een iPad en het ondertekende document weer als bijlage op te nemen in een antwoord. Erg handig. Dat soort integraties vind ik heel bruikbaar en de keuze om PDF onder water zoals PageFault hieronder aangeeft als basis voor grafische afhandeling in het os te stoppen lijkt me aan de basis van die handigheden te liggen. Vandaar mijn vraag hoe ver Windows daarmee is. In sommige opzichten best ver dus zo te lezen, maar met een andere insteek waardoor bepaalde handigheden dus niet terugkomen in de opties van systeemeigen programma’s. Wat Preview is voor macOS bestaat van nature dus niet in Windows en opslaan als pdf is dus een pure afdruktaak in Windows (je vindt afdrukken als pdf bij de afdruktaken ook in macOS terug overigens).
Logisch, onder water is de grafische structuur in macOS PDF. In Windows was dat t/m Windows XP GDI ("EMF") en vanaf Vista werd het XPS. Overal in Windows kun je heel gemakkelijk XPS genereren.
Ook de verkenner previews werken met PDF. Hoe meer door het systeem wil je het hebben?
Windows heeft toch edge, met pdf support, ingebouwd?
Oke ik werk niet zoveel met Windows, zijn elementen van Edge dan ook in andere programma’s en contextmenu’s beschikbaar zoals je dus met macOS vanuit elk willekeurig contextmenu (waar dat van toepassing is uiteraard) pdf’s kunt creëren?
Je kunt printen naar pdf? Meestal is er een print optie in het contextmenu
Ik heb ontdekt dat waarschijnlijk de reden voor Chrome de ondersteuning voor PDF bestanden te kunnen openen komt door Chromebooks. Daar kan je dan gewoon alles op 1 programma laten draaien zal vast het idee er achter zijn.
Ik gebruik chrome als standaard PDF viewer op m'n werk. Lekker makkelijk omdat ik m'n browser toch altijd open heb.
Deze functie is zeer welkom, nooit bij stil gestaan dat ik het miste.
Vind zelf de in-browser PDF viewer niet echt heel fijn, heb daarom ook nog gewoon de Adobe reader op het systeem staan, om 1 of andere reden vind ik die veel fijner lezen.. (Windows 10).
Amai wat een innovatie. Je kan toch evengoed 2 chrome vensters naast elkaar zetten via Windows Snap?
Ik denk dat het voordeel juist is dat je twee pagina's uit één document naast elkaar ziet. Dat gaat wat minder praktisch met twee browsers naast elkaar. Neemt niet weg dat me dit niet een bijzonder complexe operatie lijkt...
Nu is het nog wachten op een dark mode in de pdf viewer...
Tsja nog meer geheugenvretende shit. Ik open vaker firefox dan chrome de laatste tijd ivm geheugengebruik. Firefox is ook sneller heb ik het idee dan chrome.
Firefox slurpt iig. minder data naar Google.
Ohhja dat zal het zijn inderdaad.

Op dit item kan niet meer gereageerd worden.