[vertaling: TK]

Apple heeft aangekondigd dat Chief Design Officer Jony Ive later dit jaar weggaat bij Apple om een onafhankelijk ontwerpbedrijf te starten waarvan de Financial Times zegt dat het LoveFrom zal heten. Na de dood van Steve Jobs werden Ive en zijn ontwerpen beschouwd als een cruciale factor in het durende succes van Apple. Zijn vertrek, en dan vooral na dat van Angela Ahrendts (zie “Hoofd verkoop bij Apple Angela Ahrendts verlaat Apple in april”, 7 februari 2019), zal ongetwijfeld vragen oproepen. Apple was er dan ook als de kippen bij om bekend te maken dat zij een van de belangrijkste klanten van het nieuwe bedrijf van Ive worden.

Ive mag dan wel grotendeels het ontwerp van baanbrekende producten zoals de oorspronkelijke iMac, iPod en iPhone op zijn conto schrijven, maar ontwerpflops zoals de iPod Hi-Fi, de ronde Mac Pro, Magic Mouse 2 en de Apple Pencil van de eerste generatie kwamen ook uit tijdens zijn dienst. Erger nog, de obsessie met dunheid van Apple onder Ive heeft tot onpopulaire technische beslissingen geleid, zoals het verlies van de koptelefoonaansluiting op iPhones, de noodzaak om dongles te gebruiken voor veel MacBook-gebruikers, en niet het minst de complete ramp van het vlinder-toetsenbord (zie “Apple update de MacBook Pro's met 8-kerns processoren en een toetsenbord-reparatie(?)”, 21 mei 2019). Het stuk van John Gruber op Daring Fireball gaat over de fouten in ontwerpen van Ive in het tijdperk na Jobs. Naar verluidt zou Ive de laatste jaren minder betrokken zijn geweest bij het dagelijkse werk, en hij voelde zich waarschijnlijk beperkt door zijn positie bij Apple. Sommigen zullen het vertrek van Ive betreuren, maar we zien dit beter als een gouden kans voor Apple om een nieuwe richting op het vlak van ontwerp in te slaan.

[vertaling: DPF, PAB]

Als Apple nieuwe versies van macOS aankondigt, zegt het bedrijf vaak ook iets over versies daarna. In de eerste toelichting van de macOS 10.15 Beta staat onder het kopje Deprecations:

Scripttalen zoals Python, Ruby en Perl worden bij macOS bijgeleverd voor compatibiliteit met software uit het verleden. Toekomstige versies van macOS zullen standaard geen scripttalen bevatten, je zult ze wellicht apart moeten installeren. Als je software afhankelijk is van scripttalen bevelen we aan dat je de runtime combineert met de app.

Wat betekent deze toelichting?

De meest absolute interpretatie is dat Apple “[alle] toekomstige versies” na Catalina bedoelt, en dat die dus niet de runtimes zullen hebben die nodig zijn om scripts in deze scripttalen uit te voeren.

Het uitfaseren van systeemelementen door Apple betekent echter niet altijd dat deze volledig verwijderd worden. Toen Apple in Mac OS X 10.4 Tiger launchd introduceerde, werd cron uitgefaseerd. We zijn nu tien macOS-versies later en cron neuriet nog steeds mee en kan nog steeds gebruikt worden.

Het zou dus een storm in een glas water kunnen zijn als Apple ook in dit geval geen gevolg aan deze dreiging geeft. Maar het duurt nog minstens een jaar voor hier duidelijkheid over komt, en we moeten dus wel de gevolgen overwegen voor het geval Apple deze technologieën inderdaad in de prullenmand gooit.

Wat is de reden om deze scripttalen te verwijderen?

Dat zijn er drie: veiligheid, efficiëntie en focus.

Deze talen zijn gemeengoed in op Unix gebaseerde systemen en zijn al aanwezig in Mac OS X sinds 2001, dus waarom zou je ze nu verwijderen? Apple heeft voortdurend aanpassingen gemaakt in macOS om het veiliger te maken, en dat is waarschijnlijk de belangrijkste motivatie voor deze verandering. Gatekeeper voorkomt dat programma's van onbekende ontwikkelaars automatisch gedraaid worden, maar scripts zijn slechts tekstbestanden die nogal wat schade zouden kunnen aanrichten als ze uitgevoerd worden.

Het verwijderen van scripttalen zal er ook voor zorgen dat macOS minder schijfruimte gebruikt. De runtimes zijn klein, maar net zoals bij andere programmeertalen kunnen ze veel codebibliotheken gebruiken. macOS heeft hier duizenden van, van in totaal meer dan 150 MB. Misschien met de huidige opslagmogelijkheden niet heel veel, maar wel een factor van betekenis bij een besturingssysteem dat miljoenen keer gedownload wordt.

Als laatste is er in bedrijfsvoering een principe dat zegt dat je je moet richten op je kracht. Het ondersteunen van deze talen is geen kracht van Apple. Het bedrijf blijft niet bij met updates en gebruikers kunnen niet eenvoudig standaardgereedschappen gebruiken om extra bibliotheken te vinden en installeren, terwijl die er wel zijn.

Wie heeft hier last van, en wat zijn de mogelijkheden?

Hoe veel last je van deze mogelijke beslissing hebt, hangt ervan af wie je bent.

Scriptschrijvers

De mensen die de scripttalen goed kennen, zullen er waarschijnlijk het minste last van hebben. Als je scripts schrijft voor webontwikkeling, wetenschappelijke analyse of ander werk doet met deze scripttalen weet je waarschijnlijk al dat het bijhouden van de standaardinstallaties niet de Apples sterkste kant is.

Al lange tijd installeren ervaren gebruikers aparte kopieën van de talen in aparte mappen zodat die eenvoudig bijgewerkt kunnen worden en bibliotheken snel toegevoegd kunnen worden. Dat zal vrijwel zeker mogelijk blijven als Apple de talen uit de standaard installatie verwijdert.

App-ontwikkelaars

Mac-apps zijn geschreven in gecompileerde talen maar bevatten soms scripts om de apps bepaalde taken te laten uitvoeren. De toelichting van Apple stelt dat de ontwikkelaar dan de runtime van een script moet bijvoegen bij de applicatie. Dit verplaatst de verantwoordelijkheid naar de ontwikkelaar.

Hoewel het inefficiënt lijkt dat meerdere apps een eigen kopie van bijvoorbeeld Perl nodig gaan hebben, hoeft dat alleen maar te gaan om de runtime en de specifieke bibliotheken die vereist zijn. Sommige apps gebruiken deze route al bij Java, en veel moderne apps vertrouwen op het framework Electron, dat Node bijlevert om JavaScript te kunnen draaien.

Ontwikkelaars kunnen ook overstappen op gecompileerde code, hetzij door de scripts opnieuw te schrijven in een andere taal of door een tool te gebruiken die scripts kan converteren naar een binary executable formaat.

Mac-beheerders

Mensen die veel computers voor een school of bedrijf beheren, vertrouwen op automatisering en automatisering maakt op zijn beurt veel gebruik van scripting. Hoewel de meeste app-ontwikkelaars al gewend zijn om met Apples beveiligingsmaatregelen voor gecompileerde code om te gaan, zijn Mac-beheerders dat niet, dus het zal voor hen veel moeilijker zijn om de scripting-gewoonte te stoppen.

Hoewel sommige beheerders een of meer van deze scripttalen vloeiend beheersen, zijn er veel meer zoals ik, met net genoeg kennis om ermee door te kunnen en scripts te gebruiken die door de gemeenschap worden gedeeld. Zo is Munki van Greg Neagle een populaire opensource-tool voor het beheren van Mac-software-installaties geschreven in Python, maar je hoeft niet vloeiend in Python te zijn om het te gebruiken. Beheerders hebben momenteel de neiging om nuttige scripts te verzamelen die in verschillende talen zijn geschreven, maar het installeren en onderhouden van meerdere talen op elke Mac is te veel werk, dus in de toekomst zullen beheerders er waarschijnlijk maar één kiezen, waardoor het aantal bruikbare hulpmiddelen wordt beperkt. Voor eenvoudigere taken kunnen beheerders ook overschakelen naar het gebruik van shell-scripts, die minstens zo lang zullen meegaan als de app Terminal bij macOS zit inbegrepen.

Apple

Voordat Apple deze scripttalen uit macOS verwijdert, moet Apple iets doen aan zijn eigen gebruik ervan. Xcode bevat veel bibliotheken in alle drie genoemde talen, maar het zou voor Apple een kleine moeite moeten zijn om de runtimes toe te voegen aan de toch al enorme installatie van Xcode. iMovie bevat een alleenstaand Perl-script en het zou me niet verbazen als Apples professionele apps zoals Final Cut Pro X en Logic Pro X er ook wat bevatten.

Naast de apps van Apple bevat macOS 10.14 Mojave meer dan 175 scripts buiten de mappen die zijn toegewezen aan Perl, Python en Ruby. Sommige zijn een deel van de taal, alleen op een andere plaats, maar de rest heeft verschillende doelen. Toen ik eenmaal besefte hoeveel er zijn, leek het mij veel minder waarschijnlijk dat alle drie talen na Catalina in de macOS-versie zouden worden verwijderd.

Alle anderen

Het is moeilijk te zeggen hoeveel gewone gebruikers vertrouwen op ten minste één programma dat ten minste één script bevat. Voor actief onderhouden programma's lost de ontwikkelaar dit voor de eindgebruiker op. Voor sommige open-sourceprojecten, met name platformonafhankelijke projecten waarvoor macOS niet het primaire platform is, komen projectbijdragers er mogelijk niet aan toe om een oplossing in te bouwen.

Voor die gevallen en voor programma's die niet langer worden onderhouden, is er een oplossing: installeer zelf de scripttaal. Elke scripttaal heeft zijn eigen methode voor Mac-installatie, maar de eenvoudigste en meest gebruikte methode is een algemeen pakketbeheersysteem zoals Homebrew. Homebrew zelf bestaat uit Ruby-scripts, maar ik verwacht dat de ontwikkelaars de waarschuwing van Apple zullen opvolgen en die runtime zullen toevoegen voordat Ruby verdwijnt in een toekomstige versie van macOS.

Als je benieuwd bent hoeveel van je programma's scripts in deze talen bevatten, gebruik dan deze opdracht in Terminal:

find /Applications -type f | while read in ; do if file -b "${in}" | grep -q 'Perl\|Python\|Ruby' ; then echo "${in}" ; fi ; done

De eerste parameter na find is de map die moet worden bekeken. Op mijn Mac bevat Plex Media Server veel Python-scripts en BBEdit kent er een paar, evenals een handvol andere programma's, over het algemeen van kleinere bedrijven of open-sourceprojecten.

Trek je plan

Het punt van aankondigingen over uitfaseren is om mensen tijd te geven om wijzigingen aan te brengen, maar meestal werken deze meldingen niet volgens een vaste planning. Als Apple zelf geen prioriteit kan geven aan het beëindigen van zijn afhankelijkheid van scripts, of als het bedrijf van belangrijke partijen hoort dat die nog niet klaar zijn, kunnen een of meer talen rond blijven hangen.

Zelfs als Apple in 2020 alle scripttalen uit macOS-versie 10.16 verwijdert, is het niet zo belangrijk als andere uitfaseringen, zoals het einde van 32-bits programma-ondersteuning dat in macOS Catalina zijn beslag krijgt. In tegenstelling tot die wijziging kan je, als Apple een scripttaal verwijdert, die altijd weer terugzetten.

Nog een laatste opmerking. Swift kan gebruikt worden als een scripttaal en hoewel de runtime momenteel niet is opgenomen in macOS, kan Apple die op een bepaald moment als pleister op de wonde opnemen als de scripttaal-keuze op de Mac.

Curtis Wilcox is een op Apple gefocuste IT-beheerder aan de Harvard University, waar hij klassikale instructie, mediaproductie en projecten ondersteunt om de toegankelijkheid te verbeteren.

[vertaling: HV, JO]

Als ik een woord hoor dat ik niet ken, of als ik maar niet op het juiste woord kan komen voor de zin waar ik aan bezig ben, roep ik de hulp in van het gratis programma Terminology. Terminology is een krachtig hulpprogramma voor de iPhone en iPad van Agile Tortoise, de makers van Drafts.

Net zoals Drafts je een gereedschap geeft om aantekeningen en concepten te maken, biedt Terminology je een handvat om naar woorden te zoeken, en zijn uitbreidbare acties zijn zo krachtig dat je vrijwel altijd zult vinden waar je naar op zoek bent.

De basis van Terminology

Terminology is eerst en vooral een op zichzelf staand woordenboek en thesaurus. Na door een snelstarthandleiding meegenomen te zijn, kun je een woord opzoeken, waarbij je onmiddellijk een resultaat te zien krijgt in de vorm van definities, synoniemen en antoniemen.

Daarenboven toont de thesaurus van Terminology ook specifiekere en minder specifieke woorden. Zo krijg je bij de zoekterm 'dive' als minder specifiek woord 'swim', en als specifiekere woorden 'belly flop', 'jackknife', en 'swan dive'.

Terminology maakt het eenvoudig om gerelateerde woorden te selecteren om de resultaten voor deze woorden te zien, achteruit en vooruit te lopen door je zoekgeschiedenis en, voor mij het allerbelangrijkst, een draad van termen te volgen, waar die dan ook toe leidt. Met de luidspreker-, potlood- en hart-icoontjes rechtsboven kun je elk willekeurig woord laten uitspreken, annoteren, en tot favoriet bombarderen waar je later nog eens naar wilt kijken. Ik gebruik meestal mijn zoekgeschiedenis en geen favorieten. Je aantekeningen, favorieten, geschiedenis en instellingen worden gesynchroniseerd tussen je apparaten via iCloud, je hebt dus geen apart account nodig.

Om een woord te zoeken, is het niet altijd nodig om de app te openen, op het vergrootglas te tikken en een woord in te tikken in het zoekveld. Je kunt ook direct vanuit de bijbehorende widget (die ook fungeert als een Word of the Day-gereedschap) in het programma duiken of een woord of uitdrukking selecteren in een andere app, waarna je in de popover Share intikt om naar het deelpaneel te gaan, en de deelpaneel-uitbreiding van Terminology in de bovenste rij te kiezen om de bijbehorende zoekresultaten te zien. De eerste keer dat je dat doet, moet je wel Terminology in het deelpaneel activeren.

Mijn ervaring is dat dit erg handig is als je in iOS schrijft. Als een door mij geschreven woord of uitdrukking niet helemaal senang klinkt, kan ik het stukje tekst selecteren, Terminology openen via het deelpaneel en blijven doorklikken tot ik een geschikt alternatief vind. Dat kopieer ik vervolgens met een tik naar het klembord om het daarna in mijn schrijf-app te plakken.

Terminology-acties

Allemaal prima eigenschappen, maar op zich niet genoeg om Terminology te onderscheiden van een huis-tuin-en-keukenwoordenboek en thesaurus zoals die van Merriam-Webster, Dictionary.com of Oxford. Acties zijn de geheime kracht van Terminology, waardoor het een ongemeen krachtig gereedschap wordt voor auteurs en woordnerds. Acties lijken wellicht onbelangrijk, maar voor mij maken ze in het dagelijkse gebruik een wereld van verschil.

Als de resultaten uit het woordenboek of de thesaurus van Terminology niet zijn wat je zoekt, kun je op een actie tikken en meteen resultaten te zien krijgen vanuit andere bronnen, zonder een andere app te moeten openen of je zoekopdracht opnieuw in te moeten tikken. Acties kunnen zowel bovenaan het scherm (als knoppen) als onderaan het lemma voor een woord (als tekstkoppelingen) staan, en je kunt zelf kiezen welke acties waar opduiken.

De gratis versie van Terminology heeft standaard de volgende acties, allemaal inline: Look Up (voor het ingebouwde woordenboek), Wikipedia, Google, Etymonline (voor informatie over de geschiedenis van een woord), IMDb, en Wolfram Alpha. Die laatste is wellicht de interessantste, omdat die je onder andere afbreekregels geeft, eerst bekende gebruik en andere etymologische wetenswaardigheden, een grafiek met woordfrequenties, rijmwoorden, verwante woorden, anagrammen, vertalingen, internetdomeinen, hints voor kruiswoordpuzzels, de Scrabble-woordscore, en de bijbehorende cijfers van een toetstelefoon. Sommige woorden hebben zelfs domeinspecifieke informatie. Zoek maar eens op een muziekinstrument.

De Pro-functies van Terminology

Agile Tortoise biedt een eenmalige aanschaf van Pro-functionaliteit voor $ 1,99. Deze upgrade ontsluit een paar zaken die je zou verwachten van een eenvoudige in-app "steun de ontwikkelaar"-aankoop: Donkere modus, de mogelijkheid om de app automatisch te laten kiezen tussen lichte en Donkere modus, afhankelijk van de omgevingsverlichting, en twee alternatieve app-icoontjes.

De ingebouwde acties doen de gratis versie van Terminology al erg positief afsteken tegen de concurrentie, maar het zijn het de zelf in te stellen acties die de Pro-versie echt waardevol maken. Vanuit de bibliotheek kun je met één tik nieuwe acties toevoegen, maar je kunt ze ook helemaal zelf bouwen. Ik heb daar zelf nooit de noodzaak toe gevoeld, maar ik gebruik wel een aantal meegeleverde acties, omdat ik daarmee met één tik toegang krijg tot extra informatiebronnen, zoals de Urban Dictionary en Rhymer. Als je bovendien, net als ik, nog een aantal andere iOS-apps gebruikt voor een aantal van die bronnen (zoals V for Wikipedia of de app WolframAlpha), dan kun je acties bouwen die resultaten direct in die apps openen.

Hier is de complete lijst ingebouwde acties in Terminology (de gratis items zijn schuingedrukt):

• Woordenboeken
  • Look Up (die de systeemwoordenlijst doorzoekt)
  • Wordnik
  • Dictionary.com
  • Wiktionary
  • Merriam-Webster
  • Oxford English
  • Websters (1913)
  • Urban Dictionary
  • Free Dictionary
• Thesaurus
  • Thesaurus.com
  • Merriam-Webster Thesaurus
  • Free Thesaurus
• Naslagwerken
  • Wikipedia
  • Wolfram Alpha
  • Etymonline
  • IMDb
  • Google Scholar
• Zoekmachines
  • Google
  • YouTube
  • Google Image Search
  • DuckDuckGo
  • Bing
  • ImageNet
• Overig
  • Rhymer (voor rijmwoorden)
  • RhymeZone
  • Giphy
  • Google Translate
  • TV Tropes
  • Snopes
  • Emojipedia
• Apps
  • Drafts (stuurt de term naar Drafts)
  • Drafts Definition (stuurt de definitie naar Drafts)
  • WolframAlpha-app
  • V for Wikipedia
  • Wikipedia-app

Terminology voor macOS

Agile Tortoise maakt ook een versie van Terminology voor macOS, maar dat is niet echt een app. Het bedrijf heeft gewoon de woordenlijst en het woordenboek van Terminology toegankelijk gemaakt als zoekoptie in de app Woordenboek van macOS zelf. Heel prettig om te hebben, en helemaal omdat hij gratis is. Maar je krijgt niet alles wat de iOS-versie wel biedt, dus ik gebruik hem maar weinig.

Als je de macOS-versie wilt proberen: weet dat de installatie ervan tamelijk ingewikkeld is. Je moet het bestand Terminology.dictionary handmatig in de juiste map zetten, en daarna moet je Terminology activeren in de instellingen van de app Woordenboek. Agile Tortoise biedt wel een heldere installatiegids.

Dus probeer die Mac-versie vooral als je wilt, maar Terminology for iOS is de echte aanrader. Je downloadt hem gratis uit de App Store. Kies de in-app aankoop om de Pro-mogelijkheden te ontsluiten ($ 1,99).

Timothy Buck werkt in San Francisco als productmanager, podcast-maker en schrijver. Hij is gastheer en producent van twee podcasts, namelijk UNCO en Accessible. Je kunt zijn werk bekijken op timothybuck.me.

[vertaling: LmR, TK]

Toen Apple eerder dit jaar de iWork-apps bijwerkte (zie “iWork-update brengt iOS-apps dichter bij elkaar”, 2 april 2019), vermeldden de "Nieuw in" pagina's voor Pages 8.0 voor Mac, Pages 5.0 voor iOS en Pages voor iCloud allemaal een "inhoudsopgaveweergave" als de voornaamste nieuwe functie. Mensen die al lang Pages gebruiken en deze pagina's slecht vluchtig doornamen, zij vergeven dat ze denken "Wacht effe, Pages kon toch al lang inhoudsopgaven maken?”

Zij hebben deels gelijk. Pages voor Mac kan al tijden een inhoudsopgave invoegen in een document als onderdeel van de hoofdtekst. De andere versies van Pages konden dit echter niet en de inhoudsopgaven die Pages voor Mac in de documenten invoegden, waren ongetwijfeld handig voor de lezers van die documenten maar waren geen fatsoenlijke navigatiemethode voor de schrijvers.

De nieuwe inhoudsopgaveweergave in de jongste versie van Pages biedt die navigatiehulp nu wel. In een zijbalk (op de Mac) of in een popover (in iOS en in de iCloud-app) wordt de inhoudsopgave automatisch bijgewerkt terwijl je aan een document werkt en kun je snel door je document gaan: klik of tik simpelweg op een onderdeel in de inhoudsopgave en je springt er meteen heen. Zoals je mag verwachten, gaat het vullen van de inhoudsopgaveweergave bijna moeiteloos. Maar deze nieuwe weergave biedt nog andere voordelen.

Een navigeerbare inhoudsopgave maken

Inhoudsopgaven in Pages zijn gebaseerd op stijlen. Dit betekent dat een inhoudsopgaveweergave die alinea's in het document aangeeft waar specifieke alineastijlen op zijn toegepast.

Welke stijlen? Dat bepaal jij. Doorgaans wil je dat inhoudsopgave-onderdelen korte koppen zijn, dus als je document zulke koppen heeft, en als je iedere kop dezelfde alineastijl hebt gegeven, kun je die koppen-stijl opnemen in de inhoudsopgaveweergave.

Je gebruikt de optie Selecteer stijl om de alineastijlen te kiezen waar je inhoudsopgaveweergave naar zoekt bij het verzamelen van onderdelen. Alle drie Pages-apps hebben een Pas stijlen aan-knop bovenin de inhoudsopgaveweergaves die, als je erop klikt of tikt, deze opties toont. Onder opties worden alle alineastijlen in het document getoond met een vinkbox naast iedere stijl. Zet een vinkje in de box en de alinea's met die stijl verschijnen in de inhoudsopgaveweergave. Je kunt ook onderin de inhoudsopgaveweergave een visuele hiërarchie opstellen met de commando's verhoog en verlaag inspringniveau die bij iedere stijl horen.

Het standaard sjabloon Leeg in Pages heeft al een aantal handige alineastijlen en vier hiervan (Koptekst, Koptekst 2, Koptekst 3, en Koptekst rood) zijn alvast voorgeselecteerd om opgenomen te worden in de inhoudsopgaveweergave van het sjabloon Leeg. Als je die stijlen gebruikt in enig document dat op dat sjabloon is gebaseerd, heb je automatisch een handige inhoudsopgaveweergave. Veel van de andere sjablonen in Pages hebben ook vooringestelde inhoudsopgave-stijlen. Merk op dat het niet uitmaakt of je het uiterlijk van deze stijlen aanpast, zelfs niet als je ze hernoemt: zolang ze zijn aangemerkt om te worden opgenomen, zullen alinea's met die stijlen in de inhoudsopgaveweergave verschijnen.

Een inhoudsopgave invoegen in de tekst van een document

De nieuwe inhoudsopgaveweergave belet je overigens niet een inhoudsopgave in de tekst van een document op te nemen. Je kunt dit nog steeds doen in Pages op de Mac en nu kan het ook in Pages voor iOS.

Sterker nog, de nieuwe inhoudsopgaveweergave versimpelt het proces: zet je invoeg-punt waar je de inhoudsopgave wilt laten verschijnen en klik of tik op Voeg inhoudsopgave in onderaan de inhoudsopgaveweergave (in zowel de Mac als iOS-versies, maar niet in de iCloud-app). Alle onderdelen van de inhoudsopgaveweergave worden nu ingevoegd in het document, voorgeselecteerd en klaar voor opmaak.

Helaas kun je niet heel veel aan de opmaak van een ingevoegde inhoudsopgave doen. Zo kun je geen individuele woorden of tekens binnen de ingevoegde inhoudsopgave selecteren, maar je kunt wel alle onderdelen op ieder niveau van de inhoudsopgave selecteren. Het is allemaal alinea-opmaak, zonder aanpassingsmogelijkheden op tekenniveau.

Als je onderdelen van een ingevoegde inhoudsopgave selecteert, bieden de Opmaak-inspectors op de Mac en in iOS een Tekst-tab met de volgende opmaak-instellingen:

• Je kunt het lettertype en de tekstkleur, -stijl en -grootte instellen.
• Je kunt de onderdelen links, rechts of gecentreerd uitlijnen.
• Je kunt de afstanden tussen regels en alinea's aanpassen.
• Je kunt de paginanummers tonen of verbergen waar ieder onderdeel begint.

Bovendien kun je met de opmaak-inspector op de Mac een tab-stop instellen die aangeeft waar de paginanummering verschijnt. Ook kun je opvultekens instellen.

De onderdelen van een ingevoegde inhoudsopgave hoeven niet overeen te komen met die in de inhoudsopgaveweergave. Met andere woorden: je kunt een andere inhoudsopgave voor navigatie hebben dan voor het document. Als je een ingevoegde inhoudsopgave selecteert, kun je met de Opmaak-inspectors op zowel de Mac als in iOS stijlen aanpassen: je kunt een aantal aparte alineastijlen instellen om de onderdelen van de ingevoegde inhoudsopgave te definiëren. Je kunt de ingevoegde inhoudsopgave ook opdelen, zodat ieder deel van je document zijn eigen inhoudsopgave krijgt.

Waarom nu de functie inhoudsopgave verbeteren?

Apple is al een tijdje bezig met zijn iWork-apps voor iOS even krachtig te maken als de Mac-versies, en je kunt de nieuwe mogelijkheid om in Pages voor iOS een inhoudsopgave aan te maken in het verlengde hiervan zien. De reden waarom Apple dit zou willen doen, ligt voor de hand: met de komst van de iPad Pro heeft het bedrijf de iPad geherpositioneerd van in de eerste plaats een apparaat voor het consumeren van content naar een mobiel productiviteitsapparaat met een optioneel toetsenbord. iWork krachtiger maken op een iPad past in die strategie.

Maar volgens mij is dat niet de enige reden voor inhoudsopgaven in Pages. Recent is Apple zich meer gaan toeleggen op zijn afdeling Diensten, waar onder meer de winkel Apple Books onder valt. Pages kan al lang documenten exporteren als EPUB, het standaardformaat van Apple Books, en recent heeft Apple een nieuw item in het menu Archief van Pages voor Mac en het menu Meer (•••) van Pages voor iOS toegevoegd: Publiceer op Apple Books. Hiermee kunnen gebruikers van Pages gemakkelijk e-boeken maken om via Apple Books te verkopen of te verdelen. De nieuwste update van Pages van deze week bevat zelfs een nieuw sjabloon voor een roman als e-boek.

Waar komen de inhoudsopgaven in deze e-boeken vandaan? Van de nieuwe, gebruiksvriendelijke, bijna automatische (als je de juiste stijlen gebruikt) weergave Inhoudsopgave. Als Apple zijn aanbod in de boekenwinkel wil uitbreiden met zelf gepubliceerde boeken, dan kan een robuuste en gebruiksvriendelijke app voor het schrijven van e-boeken op elke Mac en elk iOS-apparaat hierbij zeker helpen.

Of deze toevoeging aan Pages ook algemener resultaten boekt, valt natuurlijk nog af te wachten, maar zelfs als de meeste gebruikers nooit een e-boek maken met Pages, dan nog zal de nieuwe weergave Inhoudsopgave voor velen een nuttige toevoeging zijn. Het is een voorbeeld van wat Apple kan wanneer zij hun best doen: krachtige mogelijkheden bieden in een aantrekkelijk en gebruiksvriendelijk pakket.

Opmerking: delen van dit artikel zijn in aangepaste vorm overgenomen uit Take Control of Pages, Second Edition en worden met toestemming gebruikt. Het 347 pagina's tellende boek biedt een uitgebreide documentatie van alle mogelijkheden van Pages, op elk platform. Als je precies wilt weten hoe je een Inhoudsopgave (of wat dan ook) kunt aanmaken en bewerken, koop dan dit e-boek.