.NET 10 na Azure Linux: DOCX→PDF a merge pipeline

Publikováno: 2026-05-21

Krátká odpověď

Ano, technicky jsou možné obě pipeline:

Pipeline A: více DOCX sloučit → výsledný DOCX převést do PDF
Pipeline B: každý DOCX převést samostatně do PDF → výsledná PDF sloučit

Pro Azure/Linux/.NET 10 je jako výchozí architektura výrazně bezpečnější a provozně jednodušší Pipeline B.

Doporučení

default: DOCX → PDF per dokument, potom PDF merge
primární komerční stack: Aspose.Words + qpdf nebo komerční PDF SDK
open-source / cost-sensitive fallback: LibreOffice headless pro DOCX→PDF, qpdf/pdfunite pro PDF merge
DOCX merge před konverzí používat jen tehdy, když opravdu potřebujete zachovat globální Word semantiku napříč dokumenty: jednotné číslování stránek, jeden TOC, průběžné sekce, společné záhlaví/zápatí apod.

Proč je Pipeline B obvykle lepší

Hlavní důvod: DOCX není fixed-layout formát. Je to balík XML částí, stylů, číslování, relací, sekcí, hlaviček/patiček, obrázků, poznámek, comments, tracked changes a fieldů. Slučování více DOCX s vysokou věrností je aplikačně výrazně složitější než následné sloučení PDF.

Pipeline B omezuje riziko tím, že:

každý DOCX rendrujete izolovaně
chyby ve stylech nebo numbering konfliktech se nešíří mezi dokumenty
můžete retryovat jen vadný dokument
merge fáze už pracuje nad fixed-layout výstupem
horizontální škálování je jednodušší
výsledky bývají determinističtější

Kdy dává smysl Pipeline A

Pipeline A dává smysl hlavně v edge-case scénářích:

potřebujete jeden společný obsah / TOC přes všechny vstupní dokumenty
potřebujete souvislé číslování stránek počítané jako jeden Word dokument před rendrem
potřebujete sjednotit sekce, záhlaví/zápatí a page setup ještě na úrovni DOCX
dokumenty jsou silně templated a pod kontrolou
jste ochotni investovat do testovacího korpusu a oprav merge edge-cases

Jinak je Pipeline A rizikovější.

1. Možnosti slučování více DOCX

1.1 Codeuctivity.OpenXmlPowerTools

Nejzajímavější FOSS varianta.

Plusy: - velmi dobrý kandidát pro server-side DOCX merge na .NET 10 / Linux - navazuje na známý DocumentBuilder přístup z OpenXmlPowerTools - čistě .NET, bez Office/COM - vhodné pro controlled / semi-controlled DOCX korpus

Mínusy: - stále je nutné otestovat reálné dokumenty - rizika: konflikty stylů, numbering IDs, sections, headers/footers, fields, TOC, tracked changes, comments, footnotes/endnotes, obrázky, altChunk - OpenXML knihovny typicky neobsahují plnohodnotný Word layout engine; upravují markup

Verdikt: - nejlepší open-source volba pro DOCX merge, pokud opravdu musíte mergovat DOCX před PDF

1.2 Raw Open XML SDK (`DocumentFormat.OpenXml`)

Plusy: - čistá MIT knihovna - kompatibilita s net10.0 - maximální kontrola

Mínusy: - není to hotový merge engine - naïve append body je nebezpečný - vysoká implementační i testovací složitost

Verdikt: - použít jen pokud máte velmi kontrolované šablony nebo vědomou investici do custom mergeru

1.3 OfficeIMO.Word

Plusy: - zajímavé pro generování/manipulaci s DOCX bez COM

Mínusy: - není to první volba pro high-fidelity arbitrary merge

Verdikt: - spíš controlled generation/composition než robustní merge cizích DOCX

1.4 Slabší fity

DocX: pohodlné API, ale licenční i fidelity nejistoty pro komerční server-side workload
NPOI XWPF: umí manipulaci, ale není to robustní Word merge/render engine

1.5 Komerční alternativa

Pokud chcete co nejmenší riziko a nepotřebujete FOSS-only stack, je často lepší vůbec DOCX nemergovat a jít rovnou Pipeline B. Pokud je merge DOCX business-critical, komerční Word engine typu Aspose.Words bývá bezpečnější než custom OpenXML merge.

2. Možnosti konverze DOCX → PDF na Azure Linux / .NET 10

2.1 Aspose.Words for .NET

Nejsilnější default kandidát.

Plusy: - vysoká věrnost Word renderingu - funguje bez Microsoft Office - dobře se hodí do worker/service architektury - vhodné i pro velké dávky

Mínusy: - licence / cena - je nutné pohlídat fonty, locale a image/font assets v Linux image

Verdikt: - primární doporučení pro produkční DOCX→PDF na Azure/Linux/.NET 10, pokud rozpočet dovolí

2.2 Syncfusion DocIO + DocIORenderer

Plusy: - .NET knihovny - vendor support - rozumná enterprise alternativa

Mínusy: - nutnost POC nad vlastním korpusem - licence / cena

Verdikt: - shortlist alternativa vedle Aspose

2.3 GemBox.Document / GroupDocs / další komerční SDK

Verdikt: - vhodné do vendor bake-off / POC, pokud chcete porovnat cenu a přesnost na vlastních dokumentech

2.4 LibreOffice headless

Nejlepší open-source fallback / cost-sensitive varianta.

Plusy: - bez licenčních poplatků za renderer - prakticky použitelné - vhodné jako isolated worker / sidecar / batch conversion worker

Mínusy: - vyšší provozní režie než pure .NET SDK - cold start, procesní overhead, citlivost na profily/locking/fonty - méně elegantní aplikační integrace než pure library - pro vysokou paralelizaci je vhodná izolace per worker/process/pod

Verdikt: - velmi dobrý open-source fallback nebo primary path tam, kde je cena důležitější než nejvyšší kvalita a ergonomie

2.5 Microsoft Graph / OneDrive / SharePoint conversion

Plusy: - využití Microsoft 365 ekosystému - nemusíte hostovat rendering engine sami

Mínusy: - asynchronní/cloud orchestrace - throttling, quota, latency, identity/tenant dependencies - dokumenty musí být v M365 workflow - méně vhodné pro low-latency backend conversion service

Verdikt: - jen pokud dokumenty už přirozeně žijí v Microsoft 365 a cloud workflow je žádoucí

2.6 Co nedělat

Nepoužívat server-side Office automation / COM Interop.

Microsoft výslovně upozorňuje na komplikace a nepodporovanost server-side/unattended Office Automation. Na Azure Linux to navíc ani není realistický provozní model.

3. Možnosti slučování více PDF

3.1 qpdf

Velmi silná volba pro merge hotových PDF souborů.

Plusy: - stabilní CLI nástroj - dobře zapadá do Linux worker pipeline - merge fixed-layout PDF je provozně jednoduchý - qpdf dokumentace řeší i merge velkého množství souborů a file handle strategii

Mínusy: - CLI integrace místo čisté .NET knihovny - pokud potřebujete pokročilé manipulace, forms, signing nebo compliance scénáře, může být lepší vyšší SDK

Verdikt: - výborný default pro Linux pipeline, pokud stačí merge/transformace na úrovni PDF

3.2 pdfunite / Poppler

Verdikt: - lehký open-source fallback, ale qpdf bývá univerzálnější a robustnější

3.3 Komerční PDF SDK

Příklady: - Aspose.PDF - iText Core - Syncfusion PDF Library - Docotic.Pdf - Apryse/PDFTron/Nutrient

Verdikt: - vhodné, pokud PDF merge není jen concat pages, ale součást širšího PDF workflow

4. Doporučený postup pro Azure/Linux/.NET 10

Doporučený default workflow

Validace vstupu
whitelist formátů
kontrola velikosti a page/section complexity
uložení originálů do blob storage / work storage
Konverze každého DOCX izolovaně do PDF
ideálně Aspose.Words
fallback LibreOffice headless v odděleném workeru
zachytit per-document telemetry a chyby
Merge výsledných PDF
qpdf nebo PDF SDK
Post-processing
metadata
bookmarks/attachments, pokud jsou potřeba
output validation
Uložení výsledku a audit trail
mapování input DOCX → output PDF pages / batch ID / conversion logs

Kdy přepnout na DOCX merge first

Pouze pokud business pravidla vyžadují:

společný TOC
průběžné page numbering už na úrovni Word layoutu
jednotné sekce a záhlaví/zápatí přes celé dílo
jeden finální Word dokument jako mezivýsledek nebo vedlejší artefakt

Pak:

merge dělat přes Codeuctivity.OpenXmlPowerTools nebo komerční Word engine
následně rendrovat jedním Word rendererem
povinně zavést regression corpus

5. Doporučené knihovny/služby s plusy a mínusy

Aspose.Words
plusy: kvalita, stabilita, Linux/.NET fit, bez Office
mínusy: licence, cena
LibreOffice headless
plusy: open-source, praktický fallback
mínusy: vyšší provozní režie, potřeba izolace
qpdf
plusy: robustní PDF merge na Linuxu
mínusy: CLI integrace, ne plnohodnotné PDF SDK
Codeuctivity.OpenXmlPowerTools
plusy: nejlepší FOSS kandidát pro DOCX merge před renderem
mínusy: stále nutný POC a regression testy
Syncfusion / GemBox / GroupDocs / iText / Aspose.PDF
plusy: enterprise support a širší feature set
mínusy: komerční licence a nutnost POC nad vlastním korpusem

Praktické rozhodnutí pro architekta

Varianta 1: nejnižší riziko v produkci

Aspose.Words pro DOCX→PDF
qpdf nebo Aspose.PDF pro merge PDF
Pipeline B

Varianta 2: open-source / nižší licence

LibreOffice headless pro DOCX→PDF
qpdf pro PDF merge
Pipeline B
počítat s větším DevOps/provozním laděním

Varianta 3: musíme mergovat DOCX před renderem

Codeuctivity.OpenXmlPowerTools jako první POC kandidát
případně komerční Word SDK
teprve potom PDF render
pouze pokud existuje silný business důvod

Rizika, která musíte otestovat

Bez ohledu na zvolenou variantu otestovat na reálném korpusu:

font substitution v Linuxu
page breaks a section breaks
headers/footers
obrázky, tabulky, SmartArt/charts
list numbering
footnotes/endnotes
comments/tracked changes
content controls
fields / TOC / page numbering
password-protected / malformed files
výkon při paralelních dávkách

Finální doporučení

Jako výchozí architekturu zvolit Pipeline B: každý DOCX převést samostatně do PDF a potom PDF sloučit.
Pro nejvyšší kvalitu a nejnižší implementační riziko zvolit Aspose.Words jako primární renderer.
Pro PDF merge použít qpdf, pokud stačí page-level merge; jinak komerční PDF SDK.
LibreOffice headless držet jako open-source nebo fallback variantu v izolovaném workeru.
DOCX merge před konverzí používat jen ve scénářích, kde business explicitně vyžaduje globální Word semantiku; tam je nejlepší FOSS kandidát Codeuctivity.OpenXmlPowerTools, ale pouze po POC a regression testech.
Office automation / COM Interop na serveru nepoužívat.