HTML прыходзіць радком. Стварэнне PDF пачынаецца, потым сеткавы вынятак згадвае аўтэнтыфікацыю проксі. Загляніце ў дакумент, перш чым вінаваціць PDF-файл.

Рэндэрэр можа вырашаць рэсурсы, на якія спасылаецца яго ўваход. Аддаленая выява, табліца стыляў, шрыфт або падтрыманы імпарт стварае яшчэ адзін запыт. Якія тыпы рэсурсаў падтрымліваюцца, залежыць ад рэндэрэра; падача асноўнай разметкі не гарантуе цалкам аўтаномнае пераўтварэнне.

Знайдзіце другі URL

Зафіксуйце рэсурс, які рэндэрэр атрымліваў у момант збою. Вырашайце адносныя спасылкі адносна фактычнага базавага URL. Бязьвінны на выгляд шлях да лагатыпа можа паказваць за межы праграмы, калі гэтая база адрозніваецца ад выкарыстанай у праглядзе браўзера.

Затым вызначце спампоўшчык. Паспяховы запыт вашага ўласнага HTTP-кліента не настройвае ўнутранае атрыманне рэсурсаў рэндэрэрам. Выкарыстоўвайце дакументаваны інтэрфейс рэсурсаў рэндэрэра або ўхваленую схему папярэдняй загрузкі, калі яна ёсць.

Уліковыя даныя зыходнай праграмы таксама не з'яўляюцца аўтаматычна ўліковымі данымі проксі. Рэндэрэр можа працаваць пад службовай ідэнтычнасцю з іншым асяроддзем і іншым сеткавым шляхам.

Зрабіце залежнасць яўнай

Для справаздач, прызначаных для працы аўтаномна, падавайце ўхваленыя лакальныя або ўбудаваныя рэсурсы праз падтрыманы механізм. Калі аддаленыя рэсурсы неабходныя, зрабіце іх дазволеныя прызначэнні, аўтэнтыфікацыю і паводзіны пры збоі часткай дызайну рэндэрынгу.

Адсутнае лагатыпа і няўдалае пераўтварэнне — розныя магчымыя вынікі. Праверце, як бібліятэка апрацоўвае памылкі атрымання, замест таго каб абвяшчаць справаздачу завершанай толькі таму, што створаны PDF-файл. Пакіньце няўдалы рэсурс і этап запыту ў дыягностыцы; паўторнае змяненне URL зыходнага дакумента можа пакінуць фактычнае спампоўванне некранутым.

Падобныя артыкулы