Display списъци и печатно производство

HotPDF компилира заредените page stream-ове в преизползваеми инстанции THPDFPageDisplayList с метрики THPDFDisplayListInfo и bounding box-ове на content обектите

Рендирането на документа кешира компилираните списъци, а извикващият може да поиска самостоятелно притежаван списък за многократно изпълнение или регионални заявки по обекти

Споделен production интерпретатор

Непрогресивното bitmap рендиране, direct-DC, Form и replay на display списъци минават предварително токенизирано съдържание през HPDFInterpretContentTokensDevice, който притежава обхождането на операторите и границите на отмяна

THPDFPageRenderer имплементира IHPDFContentOperatorDevice, така че споделеното обхождане вика пълната му state машина за графика, текст, ресурси, clipping, pattern, прозрачност, marked-content и image, без production рендирането да се свива до по-малкия семантичен callback повърхност

Display списъците кешират token индекси на операторите при компилация на stream-овете и при replay ползват само тези индекси, избягвайки повторни сканирания на операнди; THPDFPageDisplayList.OperatorCount и THPDFDisplayListInfo.OperatorCount излагат броя кеширани команди

Семантичните устройства, имплементиращи само IHPDFContentDevice, запазват callback-и, филтрирани по възможности, докато пълните operator устройства получават по един валидиран оператор наведнъж с по един checkpoint за отмяна на оператор

Ограничено и конкурентно рендиране

THPDFRenderTileEvent получава по една tile или хоризонтална лента с размер от извикващия наведнъж, така пикова растерна памет не зависи от размера на цялата страница

RenderLoadedPagesParallel припокрива компилацията на display списъци с възпроизвеждането, стартира първата готова страница без да чака пълен compile бариерен момент, динамично балансира двете стъпки по ограничени worker-и и връща THPDFBitmapArray в реда на входа

Компилацията върви извън заключването на кеша на display списъци, а двупроверено допускане и защитени броячи на употреба позволяват несвързани страници да се компилират конкурентно, без дублиране на публикувани записи или изхвърляне на списък по време на възпроизвеждане

THPDFParallelRenderPipelineInfo излага кеш попадения, компилации, завършвания, пикова конкуренция на компилация и рендиране, компилирани страници към първия резултат, закъснение до първия резултат и общо изминало време

RenderLoadedPagesParallelOrdered доставя callback-и в реда на входа на извикващата нишка и освобождава всеки зает bitmap след връщане на callback-а, а избраната от извикващия дълбочина на изхода прилага backpressure към producer-а и резервира по един слот за следващата нужда страница, така че бавна ранна страница не може да заклещи по-късни резултати

Подреденото стрийминг задържа най-много по един display списък и активен рендер на worker плюс ограничената опашка от завършени bitmap-и, вместо да държи целия изход на задачата резидентен

Pluggable render backend-ите консумират същите компилирани списъци през непритежаващ изглед към ресурсите на документа, така че синхронните и паралелните пътеки избягват повторен парсинг на page съдържанието, а възможностите на backend-а определят дали извикванията могат да се припокриват или изискват серийно изпращане

Планировчикът на пикова памет за целия процес вече ограничава и двата паралелни API: оценката за най-голямата страница намалява началния брой worker-и, всяка заявета страница резервира пълния си оценен working set, а подреденият изход запазва резервацията до доставянето на callback-а

Отмяната на планировчика събужда чакащите за бюджет при отмяна на callback или провал на worker, а телеметрията излага поискани спрямо действащи worker-и, пикова тежест на резервациите, забавени страници и общо време на чакане

RenderLoadedPageTilesParallel и RenderLoadedPageBandsParallel доставят заети tiles в ред на редовете или ленти отгоре надолу през изолирани worker-и, като всеки worker притежава най-много една tile, а зададен от извикващия таван за работна памет намалява конкуренцията преди първата заявка

Паралелните render контексти копират неизменими token последователности на Type 3 glyph-и и halftone threshold екрани от един ограничен LRU кеш, запазвайки локална за renderer-а собственост върху променливите graphics state и GDI ресурси

SaveLoadedPageToPng, SaveLoadedPageToPngStream, SaveLoadedPagesToTiffBanded и SaveLoadedPagesToTiffStreamBanded консумират същия band renderer чрез streaming PNG или TIFF енкодери, така че много големи страници издават компресиран изход ред по ред, без да държат пълен framebuffer, а THPDFBandImageExportInfo докладва рендерирани ленти, кодирани редове, worker-и, пикови резервирани байтове, изходни байтове, изминало време и отмяна

Споделеното декодиране на image-и се координира отделно, така че векторната работа по страниците остава паралелна, без да опетнява записите в кеша на декодирани image-и

PrefetchLoadedPages затопля растерни записи с отделен cancellation token, докато компилира и рендерира извън заключването на кеша, а рендирането на страница на преден план измества worker-а, преди да започне работа, чувствителна към закъснение

THPDFLoadedPagePrefetchInfo докладва планирана, стартирана, завършена, кеширана, рендерирана, провалена, отменена и изместена от преден план работа, заедно с последно и пикова закъснение на отмяна

Прозрачност и печатен контрол

Изравняването на прозрачността първо проверява броя прозрачности в display списъка и зададен от извикващия пиксен таван, после заменя рисуването на страницата с беззагубно Flate-компресирано калибрирано RGB изображение

Страници с Separation или DeviceN оцветители остават като векторно съдържание, като откритите оцветители и статусът на запазване се излагат на извикващия

Renderer-ът изпълнява transfer функции и halftone речници Type 1, 5, 6, 10 или 16 от ExtGState, като запазва независими RGB екрани и техните transfer замествания през q и Q

THPDFInkCoverageInfo докладва средно CMYK покритие, максимално общо покритие на площта и брой пиксели над избрания праг

Изходът за process и spot плаки поддържа оцветители DeviceCMYK, Separation и DeviceN

Преписването на цветове на заредена страница ползва същия пълен renderer, за да превръща сложни страници в Gray, RGB или CMYK, докато задържа просто device-color съдържание като вектори и прилага изрична spot-plate политика

THPDFTrappingInfo съчетава trapping декларации на документа, метаданни на страницата и структурна диагностика на TrapNet

ICC работен поток

Рендиращата трансформация може да съчетае изходен PDF профил, blend цветово пространство, proof профил, output профил и sRGB растерна цел

И четирите ICC rendering intent-а и истинската black-point компенсация се прилагат последователно към векторни цветове и image проби в целия пайплайн

Пълните трансформации се споделят между векторните, image, страниците и паралелните рендиращи пътеки през thread-safe LRU кеш от 64 MiB, ключуван по съдържанието на source, proof и output профилите, действащия rendering intent и black-point компенсацията

Изравняването на прозрачността преизползва същия трансформиращ пайплайн, после издава безшовни D65 CalRGB tiles под контролирани от извикващия бюджети за общ растер и пиксели на tile

Основни API