ASP.NET MVC एप्लिकेशन में पीडीएफ जेनरेट करने के लिए रोटाटिवा एप्लिकेशन की गैर-स्पष्ट विशेषताएं

कई डेवलपर्स वेब अनुप्रयोगों के लिए पीडीएफ रिपोर्ट बनाने के कार्य के साथ सामना कर रहे हैं, पूरी तरह से प्राकृतिक अनुरोध। रिपोर्ट उत्पन्न करने के लिए रोटेटिवा लाइब्रेरी का उपयोग करते हुए मैं इस तरह के कार्य के साथ अपने अनुभव को आपके ध्यान में लाना चाहूंगा। यह मेरे विचार में सबसे अधिक में से एक है, अपने सेगमेंट में इस तरह के उद्देश्य के लिए सुविधाजनक पुस्तकालय, लेकिन इसका उपयोग करते समय मैं कई स्पष्ट बिंदुओं पर नहीं आया, जिनके बारे में मैं बात करना चाहता हूं।

पूरी तरह से ईमानदार होने के लिए, मैं रेक के सेट को साझा करना चाहूंगा, जिसे मैंने इस पुस्तकालय को एकीकृत करने की प्रक्रिया में कदम रखा, बिना किसी संदेह के तेजी से और बहुत सुविधाजनक।

इस लेख में मैं एक पुस्तकालय चुनने के मुद्दे को संबोधित नहीं करूंगा। इस या उस का उपयोग करने के लिए हर किसी के अपने कारण हो सकते हैं। मैंने रोटाटिवा को चुना, क्योंकि न्यूनतम सेटअप लागत के साथ, इसे ग्राहकों की आवश्यकताओं को पूरा करने के लिए आवश्यक सब कुछ मिला। उसके अलावा, मैंने तीन या चार और विकल्पों की कोशिश की।

समस्या का बयान

ASP.NET MVC, .NET संस्करण 4.6 पर वेब अनुप्रयोग। अन्य विशेषताएँ इस संदर्भ में प्रासंगिक नहीं हैं, परिनियोजन के अपवाद के साथ। तैनाती Azure पर होने की उम्मीद है। यह महत्वपूर्ण है क्योंकि कुछ अन्य पुस्तकालयों (जैसे HiQPdf) कुछ Azure कॉन्फ़िगरेशन में इंस्टॉलेशन को स्थानांतरित नहीं करते हैं, यह प्रलेखित है।

मुझे एक लिंक के साथ एक निश्चित स्थिर HTML रिपोर्ट और दूसरी लिंक के साथ एक ही रिपोर्ट का एक पीडीएफ संस्करण खोलने की आवश्यकता है। रिपोर्ट ही उपयोगकर्ता के लिए प्रदर्शन के लिए कुछ तालिकाओं, फ़ील्ड्स और ग्राफ़ का एक सेट है। दोनों संस्करणों को रिपोर्ट के अनुभागों के माध्यम से नेविगेशन के साथ एक मेनू की आवश्यकता होती है, तालिकाओं की उपस्थिति, कुछ ग्राफिक्स (रंग, पाठ का आकार, सीमाएं)।

रोटाटिवा लाइब्रेरी का उपयोग करना

रोटाटिवा मेरी राय में जितना संभव हो उतना आसान है।

1. आपके पास ASP.NET MVC टेम्पलेट और नियंत्रक के रूप में पहले से तैयार HTML रिपोर्ट है, जैसे कि:

[HttpGet] public async Task<ActionResult> Index(int param1, string param2) { var model = await service.GetReportDataAsync(param1, param2); return View(model); } 

1. नगेट रोटेटिवा पैकेज स्थापित करें

   
   

2. पीडीएफ रिपोर्ट के लिए नया नियंत्रक जोड़ें

   
   

 [HttpGet] public async Task<ActionResult> Pdf(int param1, string param2) { var model = await service.GetReportDataAsync(param1, param2); return new ViewAsPdf("Index", model); } 

अनिवार्य रूप से अब से, आपके पास एक पीडीएफ है जो मूल एचटीएमएल रिपोर्ट के सभी डेटा वाली फ़ाइल के रूप में लौटा है।

मैंने यहां रूटिंग का वर्णन नहीं किया है, लेकिन यह समझा जाता है कि आपने दोनों नियंत्रकों को ठीक से कॉल करने के लिए मार्ग कॉन्फ़िगर किए हैं

दिलचस्प बात यह है कि यह लाइब्रेरी अपने आप में प्रसिद्ध कंसोल यूटिलिटी वाक्टामलटॉपडाउन पर अनिवार्य रूप से एक आवरण है। ऊंचाई पर काम की गति, आप एज़्योर पर दांव लगा सकते हैं - काम करेंगे। लेकिन ऐसी विशेषताएं हैं जिनके बारे में हम बात करेंगे।

पृष्ठ संख्या

यह मान लेना तर्कसंगत है कि ग्राहक पीडीएफ प्रिंट करेगा और पेज नंबर देखना चाहेगा। रोटाटिवा के रचनाकारों के लिए यहां सब कुछ बेहद सरल है।

CustomSwitches प्रलेखन के अनुसार, CustomSwitches पैरामीटर के माध्यम से, CustomSwitches उन तर्कों को निर्दिष्ट CustomSwitches सकते हैं जो कि wkhtmltopdf उपयोगिता में wkhtmltopdf पास हो जाएंगे। खैर, ऑनलाइन युक्तियां उदाहरणों के साथ उदार हैं। निम्न कॉल प्रत्येक पृष्ठ के नीचे एक नंबर जोड़ता है:

 return new ViewAsPdf("Index", model) { PageMargins = new Rotativa.Options.Margins(10, 10, 10, 10), PageSize = Rotativa.Options.Size.A4, PageOrientation = Rotativa.Options.Orientation.Portrait, CustomSwitches = "--page-offset 0 --footer-center [page] --footer-font-size 8 }; 

यह बहुत अच्छा काम करता है। पृष्ठ संख्या स्वयं [page] पैरामीटर का उपयोग करके पारित की जाती है, इस तरह के मापदंडों को विशिष्ट मूल्यों के साथ बदल दिया जाएगा।

[page] अलावा [page] अन्य भी हैं:

• [पेज] वर्तमान में मुद्रित किए जा रहे पृष्ठों की संख्या से प्रतिस्थापित
• [frompage] मुद्रित होने वाले पहले पृष्ठ की संख्या से प्रतिस्थापित
• [topage] मुद्रित होने वाले अंतिम पृष्ठ की संख्या द्वारा प्रतिस्थापित
• [वेबपेज] प्रिंट किए जा रहे पेज के URL द्वारा प्रतिस्थापित
• [अनुभाग] वर्तमान अनुभाग के नाम से प्रतिस्थापित
• [उपधारा] वर्तमान उपधारा के नाम से प्रतिस्थापित
• [दिनांक] सिस्टम स्थानीय प्रारूप में वर्तमान तिथि द्वारा प्रतिस्थापित
• [isodate] आईएसओ format६०१ में वर्तमान तिथि द्वारा विस्तारित प्रारूप में प्रतिस्थापित
• [समय] सिस्टम स्थानीय प्रारूप में वर्तमान समय द्वारा प्रतिस्थापित
• [शीर्षक] वर्तमान पृष्ठ वस्तु के शीर्षक द्वारा प्रतिस्थापित
• [सिद्धांत] आउटपुट दस्तावेज़ के शीर्षक द्वारा प्रतिस्थापित
• [साइटपेज] वर्तमान साइट में पृष्ठ की संख्या द्वारा परिवर्तित किया जा रहा है
• [sitepages] वर्तमान साइट में पृष्ठों की संख्या द्वारा परिवर्तित किया जा रहा है

सामग्री की तालिका

बड़ी बहु-पृष्ठ रिपोर्ट के लिए PDF सामग्री और पृष्ठ नेविगेशन की आवश्यकता होती है। यह बहुत सुविधाजनक है और बस महत्वपूर्ण है जब एक रिपोर्ट में पृष्ठों की संख्या एक सौ से अधिक हो जाती है।

Wkhtmltopdf मैनुअल में सभी विकल्पों की एक पूरी सूची है, जिसके बीच --toc । इस पैरामीटर को देखकर, उपयोगिता अनिवार्य रूप से दस्तावेज़ में सभी टैग <h1>, <h2>, ... <h6> एकत्र करती है और उनके आधार पर सामग्री की एक तालिका तैयार करती है। तदनुसार, अपने एचटीएमएल टेम्पलेट में इन हेडर टैग के सही उपयोग के लिए प्रदान करना आवश्यक है।

लेकिन वास्तव में, --toc को जोड़ने से कोई परिणाम नहीं होता है। मानो कोई पैरामीटर नहीं था। हालांकि, अन्य विकल्प काम करते हैं। कुछ मंच पर एक पोस्ट के लिए धन्यवाद, मैंने पाया कि इस पैरामीटर को हाइफ़न के बिना पारित किया जाना चाहिए: toc । दरअसल, इस मामले में, सामग्री को पहले पृष्ठ के रूप में जोड़ा जाता है। जब आप सामग्री में एक पंक्ति पर क्लिक करते हैं, तो आप दस्तावेज़ में वांछित पृष्ठ पर जाते हैं, पृष्ठ संख्याएं सही होती हैं।

यह पूरी तरह से अभी तक स्पष्ट नहीं है कि शैलियों को कैसे स्थापित किया जाए, लेकिन मैंने अभी तक ऐसा नहीं किया है।

जावास्क्रिप्ट निष्पादन

अगले बिंदु पर मुझे रिपोर्ट में ग्राफ़ जोड़ने की आवश्यकता थी। मेरे HTML पेज में JS कोड है जो dc.js लाइब्रेरी का उपयोग करके ग्राफिक्स जोड़ता है। यहाँ एक उदाहरण है:

 function initChart() { renderChart(@Html.Raw(Json.Encode(Model.Chart_1_Data)), 'chartDiv_1'); } function renderChart(data, chartElementId) { var colors = ['#03a9f4', '#67daff', '#8bc34a']; var barHeight = 45; var clientHeight = data.length * barHeight + 50; var clientWidth = document.getElementById(chartId).offsetWidth; var chart = dc.rowChart('#' + chartElementId); var ndx = crossfilter(dataToRender); var dimension = ndx.dimension(d => d.name); var group = dimension.group().reduceSum(d => d.value); chart .width(clientWidth) .height(clientHeight) .margins({ top: 16, right: 16, bottom: 16, left: 16 }) .ordinalColors(colors) .dimension(dimension) .group(group) .xAxis() .scale(d3.scaleLinear().domain([0, 2]).range([1, 3]).nice()); chart.render(); } 

उसी समय, HTML में, मेरे पास एक संगत तत्व है:

 <div id="chart_C2" class="dc-chart"></div> 

इस कोड को काम करने के लिए, आपको उचित पुस्तकालयों को आयात करने की आवश्यकता है: dc.js , d3.js , crossfilter.js । initChart फ़ंक्शन के लिए एक कॉल एक ग्राफ बनाएगा और परिणामी सम्मिलित करेगा
पेड़ में निर्दिष्ट आइटम के लिए svg।

लेकिन पीडीएफ में ग्राफ का कोई निशान नहीं है। पीडीएफ रेंडरिंग से पहले जावास्क्रिप्ट कोड निष्पादन के किसी भी अन्य निशान। यह जांचना काफी आसान है - बस पाठ के साथ एक सरल <div> तत्व बनाने के लिए प्राथमिक कोड जोड़ें, बस जावास्क्रिप्ट कॉल के तथ्य का परीक्षण करने के लिए।

जाहिर है, यह पता चला है कि wkhtmltopdf के लिए JS कोड का स्थान एक महत्वपूर्ण भूमिका निभाता है। <html> के अंत में स्थित कोड या, <body> JS के अंत में निष्पादित नहीं किया जाएगा। ऐसा लगता है कि उपयोगिता बस उसे नोटिस नहीं करती है, या वहां उससे मिलने की उम्मीद नहीं करती है।

लेकिन <head> के अंदर कोड निष्पादित होता है। इस प्रकार, मैं योजना में आया जब जावास्क्रिप्ट कोड <head> अंदर शैलियों की घोषणा के बाद स्थित है, और सामान्य निर्माण द्वारा बुलाया जाता है:

 <body onload="initCharts()"> 

इस मामले में, कोड को उम्मीद के मुताबिक निष्पादित किया जाएगा।

जावास्क्रिप्ट सीमाएँ

लेकिन फिर भी आउटपुट पीडीएफ में कोई रेखांकन नहीं था। तब मैंने अनुमान लगाना शुरू किया कि पूर्ण ब्राउज़र नहीं होने के कारण, पीडीएफ रेंडरिंग और निष्पादन इंजन सबसे अधिक सही नहीं है और पिछले नियमों को नहीं समझता है। फिर, प्रयोगात्मक रूप से, मुझे पता चला कि तीर फ़ंक्शन का अर्थ नहीं है। इसके अलावा, यदि दुभाषिया उसके लिए कुछ अज्ञात पाता है, तो यह बस काम करना बंद कर देता है।

फार्म के तीर कार्यों की जगह x => x.value अधिक शास्त्रीय function(x) { return x.value; } function(x) { return x.value; } मदद की और सभी कोड निष्पादित किए गए, जिसके परिणामस्वरूप ग्राफ एक पीडीएफ फाइल में मिला।

चार्ट की चौड़ाई

जाहिर है, यह पता चला कि ग्राफ के मूल तत्व की चौड़ाई को स्पष्ट रूप से इंगित करना आवश्यक था। इसके लिए, मैंने dc-chart शैली निर्दिष्ट की। इसमें पिक्सेल में ग्राफ की चौड़ाई होती है। अन्यथा, पीडीएफ पर चार्ट बहुत छोटा होगा, इस तथ्य के बावजूद कि HTML संस्करण में यह पूरी चौड़ाई पर कब्जा कर लेगा। प्रतिशत की चौड़ाई निर्दिष्ट करना केवल HTML के लिए काम करेगा।

इनलाइन जावास्क्रिप्ट / सीएसएस

अंत में, मैं यह नोट करना चाहूंगा कि एचटीएमएल को पीडीएफ में परिवर्तित करने वाले कई पुस्तकालय एक पैरामीटर के रूप में एक निश्चित आधार को स्वीकार करते हैं। यह URL है जिसके आधार पर कनवर्टर आयातित सीएसएस शैलियों, जावास्क्रीप्ट फ़ाइलों या फोंट को प्राप्त करने के लिए सापेक्ष पथों को पूरा करेगा। मैं यह सुनिश्चित करने के लिए नहीं कह सकता कि यह रोटाटिवा में कैसे काम करता है, लेकिन मैं एक अलग दृष्टिकोण के साथ आया था।

रिपोर्ट के प्रारंभिक लोडिंग को तेज करने और रूपांतरण के दौरान स्क्रिप्ट या शैली फ़ाइलों को एम्बेड करने की समस्याओं के स्रोत को समाप्त करने के लिए, मैं आवश्यक जेएस और सीएसएस को सीधे HTML टेम्पलेट के शरीर में एम्बेड करता हूं।

ऐसा करने के लिए, उपयुक्त बंडल बनाएं:

 public class BundleConfig { public static void RegisterBundles(BundleCollection bundles) { bundles.Add(new StyleBundle("~/Styles/report-html") .Include("~/Styles/report-common.css") .Include("~/Styles/report-html.css") ); bundles.Add(new StyleBundle("~/Styles/report-pdf") .Include("~/Styles/report-common.css") .Include("~/Styles/report-pdf.css") ); bundles.Add(new ScriptBundle("~/Scripts/charts") .Include("~/Scripts/d3/d3.js") .Include("~/Scripts/crossfilter/crossfilter.js") .Include("~/Scripts/dc/dc.js") ); } } 

इन बंडलों के लिए Global.asax.cs कॉन्फ़िगरेशन कॉल जोड़ें

 protected void Application_Start() { ... BundleConfig.RegisterBundles(BundleTable.Bundles); } 

और कोड को पेज में एम्बेड करने के लिए उचित विधि जोड़ें। इसे Global.asax.cs के समान नामस्थान में रखने की आवश्यकता है ताकि HTML टेम्पलेट से विधि को कॉल किया जा सके:

 public static class HtmlHelperExtensions { public static IHtmlString InlineStyles(this HtmlHelper htmlHelper, string bundleVirtualPath) { string bundleContent = LoadBundleContent(htmlHelper.ViewContext.HttpContext, bundleVirtualPath); string htmlTag = $"<style rel=\"stylesheet\" type=\"text/css\">{bundleContent}</style>"; return new HtmlString(htmlTag); } public static IHtmlString InlineScripts(this HtmlHelper htmlHelper, string bundleVirtualPath) { string bundleContent = LoadBundleContent(htmlHelper.ViewContext.HttpContext, bundleVirtualPath); string htmlTag = $"<script type=\"text/javascript\">{bundleContent}</script>"; return new HtmlString(htmlTag); } private static string LoadBundleContent(HttpContextBase httpContext, string bundleVirtualPath) { var bundleContext = new BundleContext(httpContext, BundleTable.Bundles, bundleVirtualPath); var bundle = BundleTable.Bundles.Single(b => b.Path == bundleVirtualPath); var bundleResponse = bundle.GenerateBundleResponse(bundleContext); return bundleResponse.Content; } } 

खैर, अंतिम स्पर्श टेम्पलेट से एक कॉल है:

 @Html.InlineStyles("~/Styles/report-pdf"); @Html.InlineScripts("~/Scripts/charts"); 

नतीजतन, सभी आवश्यक सीएसएस और जावास्क्रिप्ट सीधे HTML में होंगे, हालांकि विकास के दौरान आप व्यक्तिगत फ़ाइलों के साथ काम कर सकते हैं।

सबसे अधिक संभावना है, कई तुरंत ब्राउज़र द्वारा कैशिंग अनुरोधों के संदर्भ में इस दृष्टिकोण की अक्षमता के बारे में सोचेंगे। लेकिन मेरे दो विशिष्ट लक्ष्य थे:

• ताकि पीडीएफ कनवर्टर को शैलियों या कोड के लिए कहीं अनुरोध न करना पड़े, और उपयोगकर्ता को क्रमशः इसके लिए इंतजार करना पड़े;
• ताकि कई अतिरिक्त अनुरोधों की प्रतीक्षा किए बिना पीडीएफ और एचटीएमएल रिपोर्ट का पहला डाउनलोड न्यूनतम समय ले। मेरी परियोजना के संदर्भ में, यह महत्वपूर्ण है;

पेज टूट जाता है

एक नए पृष्ठ से एक नया अनुभाग शुरू करने के लिए आवश्यकताओं के साथ रिपोर्ट को अनुभागों में संरचित करना आवश्यक हो सकता है। इस स्थिति में, आप सरल सीएसएस दृष्टिकोण का सफलतापूर्वक उपयोग कर सकते हैं:

 .page-break-before { page-break-before: always; } .no-page-break-inside { page-break-before: auto; page-break-inside: avoid; } 

Wkhtmltopdf उपयोगिता सफलतापूर्वक इन वर्गों को पढ़ती है और समझती है कि एक नया पृष्ठ शुरू करना आवश्यक है। पहला वर्ग - page-break-before - इस तत्व के साथ हमेशा एक नया पृष्ठ शुरू करने की उपयोगिता बताता है। दूसरा वर्ग - no-page-break-inside - उन तत्वों पर लागू किया जाना चाहिए जो पृष्ठ पर यथासंभव पूरा करने के लिए वांछनीय है। उदाहरण के लिए, आपके पास संरचित जानकारी के लगातार ब्लॉक हैं, या टेबल कहते हैं। यदि दो ब्लॉक पृष्ठ पर फिट होते हैं - वे स्थित होंगे। यदि तीसरा पृष्ठ में फिट नहीं होता है, तो यह अगला नहीं होगा। यदि यह एक पृष्ठ से बड़ा है, तो इसका स्थानांतरण पहले से ही अपरिहार्य है। यह सब पर्याप्त रूप से और आसानी से काम करता है।

Wkhtmltopdf में फ्लेक्स व्यवहार

खैर, मैंने जो आखिरी विशेषता देखी वह फ्लेक्सबॉक्स मार्कअप शैलियों के उपयोग से संबंधित है। हम सभी उनके आदी हो गए हैं और लगभग सभी मार्कअप फ्लेक्स द्वारा बनाए गए हैं। हालांकि, इस संबंध में wttmltopdf थोड़ा पीछे है। क्षैतिज फ्लेक्स विकल्प काम नहीं करते (कम से कम मेरे मामले में यह काम नहीं किया। मैंने नेटवर्क उल्लेख में देखा कि यह फ्लेक्स शैलियों को डुप्लिकेट करने के लायक है:

 display: -webkit-flex; display: flex; flex-direction: row; -webkit-flex-direction: row; -webkit-box-pack: justify; /* wkhtmltopdf uses this one */ -webkit-justify-content: space-between; justify-content: space-between; 

लेकिन दुर्भाग्य से यह पीडीएफ में अपेक्षित मार्कअप नहीं हुआ। मुझे कुछ तत्वों के लेआउट को फिर से करना पड़ा ताकि ब्लॉकों की क्षैतिज नियुक्ति आवश्यकताओं के अनुसार हो। अगर किसी के पास wttmltopdf के लिए फ्लेक्स को एकीकृत करने का सफल अनुभव है, तो कृपया साझा करें। यह बहुत मददगार होगा।

कुछ लिंक:

• wkhtmltopdf
• wkhtmltopdf मैनुअल
• रोटातिवा गीथूब
• रोटाटिवा पैकेज
• इनलाइन शैलियाँ HowTo