Annotation XFDF destinations

Nativt annoterings-XFDF, Windows-filjobb och V1-återanrop samt nativa Linux V1-återanrop bevarar namngivna destinationer och lokala explicita sidmål i Link-annoteringar, med en separat extern GoToR-väg

En direkt Dest mappar till annoteringens PDF-destinationsobjekt, medan OnActivation/Action/GoTo/Dest mappar till en lokal GoTo-åtgärd; sidindex är nollbaserat och binds till det faktiska indirekta sidobjektet under importen

Attributmodellen följer Adobes XML Forms Data Format Specification, Version 3.0, tryckta sidor 59-68 och 88; PDF-destinationssemantik definieras i ISO 32000

Kanonisk XYZ-export utelämnar koordinater vars PDF-objekt är null; saknade valfria koordinater bevarar visarens aktuella koordinat eller zoom, och zoom noll behåller standard-PDF-betydelsen

Kompatibilitetsprofilen accepterar också literala null och tomma koordinatattribut som null-värden; obligatoriska FitH/FitV/FitBH/FitBV-attribut emitteras som literal null när deras PDF-objekt är null, utan ett påstående om ISO-schemacertifiering

FitR kräver alla fyra numeriska gränser; obligatoriska attribut kan inte utelämnas ur andra Fit-moden, och Page måste vara ett decimalheltal som identifierar en befintlig sida

Precision och gränser

Kvalificerade Adobe-elementnamn och ärvda namnområdesbindningar bevarar samma mål; främmande destinationsnamnområden och dubbletterade XML-attribut avvisas före annoteringsskapande

Koordinater måste vara ändliga, ha ett exakt absolut decimalvärde högst 1000000 och använda icke-negativ zoom; numerisk indata och utvidgad decimalutdata begränsas till 8192 tecken

Signerade decimaler och vetenskaplig notation accepteras inom de gränserna och skrivs sedan som PDF-decimaltoken utan exponentnotation; källtoken behåller författad precision även när det äldre publika Single-värdet avrundar eller underflödar

Sparad PDF-omläsning och efterföljande XFDF-export bevarar det behållna decimaltokenet, inklusive långa bråk nära koordinatgränsen

Transaktioner och återanrop

Den nativa filtransaktionen validerar mål före publicering, bevarar den inlästa grafen och tidigare mål vid fel och använder de befintliga annoterings-, objekt-, djup-, byte- och arbetslagringsbudgetarna

Windows- och Linux JSON-ingångspunkter använder samma mappade codec genom sina befintliga V1-operationsposter; misslyckade återanrop eller avbrott behåller den tidigare sparade PDF:n, medan anroparägda återanropsutlopp kan ha mottagit kandidatbyte

Ett misslyckat skrivåteranrop försöks inte igen genom ett aliasat utdata- eller resultatutlopp; samma regel gäller två-handle-jämförelse, och odefinierade skrivstatusvärden blir standard-IO-felstatusen

Den gemensamma HPDFXFDF codecen accepterar en separat destinationsåteranropspost i nya överladdningar; den äldre åtkomstpostens layout förblir oförändrad

THotPDF:s inlästa annoteringsmetoder binder dessa återanrop automatiskt; direkta codec-anropare måste tillhandahålla sidantal och sidupplösning för explicita mål

Gränser

Denna profil mappar lokala GoTo- och destinationsdata utan att utföra åtgärder; Launch, godtyckliga åtgärdsordlistor, destinationsnamnträdförfattande, AP-transport och annoteringsersättning/borttagning förblir separata förmågor

Mappad annoteringsprofil · Windows-operationer · Linux-återanrop