HTML ಅನ್ನು PDF ಗೆ ಪರಿವರ್ತಿಸುವುದು ಕಾಗದದ ಮೇಲೆ ಸುಲಭವಾಗಿ ಕಾಣಿಸುತ್ತದೆ. ನೀವು ಒಂದು ಸುಸಜ್ಜಿತ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ತಯಾರಿಸಿ, ಅದಕ್ಕೆ ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಸೇರಿಸುತ್ತೀರಿ ಮತ್ತು ವೆಬ್ ಪುಟದಂತೆಯೇ ಪಿಕ್ಸೆಲ್ ಪಿಕ್ಸೆಲ್ ಆಗಿ ಕಾಣುವ ದಾಖಲೆಯನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತೀರಿ. ವಾಸ್ತವದಲ್ಲಿ, ಈ ಪೈಪ್ಲೈನ್ (pipeline) ಕ್ರ್ಯಾಶ್ಗಳು, ಕಾಣೆಯಾದ ಗ್ಲಿಫ್ಗಳು (glyphs) ಮತ್ತು ದೃಶ್ಯ ದೋಷಗಳ (visual corruption) ವಿರುದ್ಧದ ದೈನಂದಿನ ಹೋರಾಟವಾಗಿ ಬದಲಾಗುತ್ತದೆ. ಇತ್ತೀಚಿನ ಯೋಜನೆಯೊಂದರಲ್ಲಿ, ಮೂರು ಸಮಸ್ಯೆಗಳು ಪದೇ ಪದೇ ಎದುರಾದವು: ಕೆಲವು SVG ಗ್ರಾಫಿಕ್ಸ್ ಬಂದಾಗ iText ಸಂಪೂರ್ಣವಾಗಿ ಕುಸಿಯುತ್ತಿತ್ತು, ಎಮೋಜಿಗಳು ಬಿಳಿ ಚೌಕಗಳಾಗಿ ಮಾಯವಾಗುತ್ತಿದ್ದವು ಮತ್ತು ಸೂಕ್ಷ್ಮವಾದ ಪಾರದರ್ಶಕ ಹಿನ್ನೆಲೆಗಳು (transparent backgrounds) ಕಪ್ಪು ಬಣ್ಣದ ಬ್ಲಾಕ್ಗಳಾಗಿ ಬದಲಾಗುತ್ತಿದ್ದವು. ಪ್ರತಿಯೊಂದು ವೈಫಲ್ಯಕ್ಕೂ ವಿಭಿನ್ನ ಕಾರಣಗಳಿದ್ದವು ಮತ್ತು ಮೂರನ್ನೂ ಸರಿಪಡಿಸಲು, PDF ಇಂಜಿನ್ ಅದನ್ನು ನೋಡುವ ಮೊದಲೇ ಅಪ್ಲಿಕೇಶನ್ ವಿಷಯವನ್ನು (content) ಹೇಗೆ ಸಿದ್ಧಪಡಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಮರುಪರಿಶೀಲಿಸಬೇಕಾಯಿತು.
SVG ಪೈಪ್ಲೈನ್ ಅನ್ನು ಕುಸಿಯುವಂತೆ ಮಾಡಿದಾಗ
iText ಅನುಕೂಲಕ್ಕಾಗಿ ಆಂತರಿಕ SVG ರೆಂಡರರ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ, ಆದರೆ ಆ ಏಕೀಕರಣವು (integration) ಒಂದು ಗಂಭೀರ ದೌರ್ಬಲ್ಯವನ್ನು ಮರೆಮಾಚುತ್ತದೆ. ಒಂದು SVG ಸಂಕೀರ್ಣ ಪಥಗಳು (complex paths), ಭಾರೀ CSS ಸ್ಟೈಲಿಂಗ್ ಅಥವಾ ಕೆಲವು ಕೋಆರ್ಡಿನೇಟ್ ಪರಿವರ್ತನೆಗಳನ್ನು ಹೊಂದಿದ್ದಾಗ, ಎಂಬೆಡೆಡ್ ಪಾರ್ಸರ್ (embedded parser) ಸುಲಭವಾಗಿ ಎಕ್ಸೆಪ್ಶನ್ (exception) ನೀಡದೆ ನಿಂತುಬಿಡುತ್ತದೆ. ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಕುಸಿಯುತ್ತದೆ. ಇವು ಎಚ್ಚರಿಕೆಯಿಲ್ಲದೆ PDF ಜನರೇಷನ್ ಥ್ರೆಡ್ ಅನ್ನು ಕೊಲ್ಲುವ ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್ಗಳಾಗಿದ್ದು, ನಿಮಗೆ ಅರೆಬರೆ ಫೈಲ್ ಮತ್ತು ವೆಕ್ಟರ್ ಪಾರ್ಸರ್ನ ಆಳದಲ್ಲಿ ಎಲ್ಲಿಯೋ ತೋರಿಸುವ ಸ್ಟ್ಯಾಕ್ ಟ್ರೇಸ್ (stack trace) ಅನ್ನು ಮಾತ್ರ ಉಳಿಸುತ್ತವೆ.
ಇದಕ್ಕೆ ನಂಬಲರ್ಹವಾದ ಪರಿಹಾರವೆಂದರೆ iText ಅನ್ನು SVG ಅನ್ನು ರೆಂಡರ್ ಮಾಡಲು ಕೇಳುವುದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಲ್ಲಿಸುವುದು. ಬದಲಾಗಿ, ಆ ಕೆಲಸವನ್ನು ಸ್ಟ್ಯಾಂಡ್ಅಲೋನ್ ಮೋಡ್ನಲ್ಲಿ ಚಲಿಸುವ Apache Batik ಗೆ ವರ್ಗಾಯಿಸಿ. Batik ಅದೇ ಸಂಕೀರ್ಣ ಪಥಗಳು ಮತ್ತು CSS ನಿಯಮಗಳನ್ನು ಅಷ್ಟೇನೂ ಅಸ್ಥಿರತೆಯಿಲ್ಲದೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸುವುದು ನಿಮ್ಮ PDF ಇಂಜಿನ್ ಅನ್ನು ಗ್ರಾಫಿಕ್ಸ್ ಸಂಬಂಧಿತ ಅಸ್ಥಿರತೆಯಿಂದ ರಕ್ಷಿಸುತ್ತದೆ. ಕಾರ್ಯವಿಧಾನವು ಸರಳವಾಗಿದೆ: ದಾಖಲೆ ತಯಾರಿಕೆ (document assembly) ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು, SVG ಅನ್ನು Batik ಮೂಲಕ ರನ್ ಮಾಡಿ ಒಂದು PNG data URL ಅನ್ನು ಪಡೆಯಿರಿ. ಕಚ್ಚಾ ವೆಕ್ಟರ್ ಮಾರ್ಕಪ್ ಬದಲಿಗೆ ಆ ರಾಸ್ಟರ್ ಇಮೇಜ್ ಅನ್ನು iText ಗೆ ಕಳುಹಿಸಿ. ದೊಡ್ಡ ಲೈಬ್ರರಿಯೊಳಗೆ ಸೇರಿಸಲ್ಪಟ್ಟ ಮತ್ತು ಸ್ಥಿರಗೊಳಿಸಲಾದ ಎಂಬೆಡೆಡ್ ರೆಂಡರರ್ ಅನ್ನು விட ಸ್ಟ್ಯಾಂಡ್ಅಲೋನ್ Batik, SVG ಸ್ಪೆಸಿಫಿಕೇಶನ್ ಅನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಅನುಸರಿಸುತ್ತದೆ ಮತ್ತು ಈ ಪ್ರತ್ಯೇಕತೆಯಿಂದಾಗಿ ಒಂದು ತಪ್ಪಾದ ಗ್ರಾಫಿಕ್ ಇಡೀ ದಾಖಲೆ ಪರಿವರ್ತನೆಯನ್ನು ಕುಸಿಯುವಂತೆ ಮಾಡಲಾರದು.
ನಿಮ್ಮ ಚಾರ್ಟ್ ವೃತ್ತಿಪರವಾಗಿ ಕಾಣುತ್ತದೆಯೇ ಅಥವಾ ಬಗ್ ರಿಪೋರ್ಟ್ನಂತೆ ಕಾಣುತ್ತದೆಯೇ ಎಂಬುದು ಒಂದು ಸಣ್ಣ ವಿವರವನ್ನು ಅವಲಂಬಿಸಿದೆ. SVG ತನ್ನ ಕೋಆರ್ಡಿನೇಟ್ ಸಿಸ್ಟಮ್ ಮತ್ತು ಸ್ಕೇಲಿಂಗ್ ವರ್ತನೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು viewBox ಅಟ್ರಿಬ್ಯೂಟ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ನಿಮ್ಮ ಪರಿವರ್ತನಾ ಕೋಡ್ viewBox ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದರೆ, ಸಂಪೂರ್ಣವಾಗಿ ಸರಿಯಾದ ಚಾರ್ಟ್ ಓದಲಾಗದ ಸಣ್ಣ ಚುಕ್ಕೆಯಾಗಿ ಕುಗ್ಗಬಹುದು ಅಥವಾ ವಿರೂಪಗೊಂಡ ಗೊಂದಲವಾಗಿ ಹರಡಬಹುದು. ಅಟ್ರಿಬ್ಯೂಟ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪಾರ್ಸ್ ಮಾಡಿ ಮತ್ತು ಆ ಆಯಾಮಗಳನ್ನು (dimensions) ನಿಮ್ಮ ಔಟ್ಪುಟ್ ಗಾತ್ರಕ್ಕೆ ಮ್ಯಾಪ್ ಮಾಡಿ. ಈ ಹಂತವನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟರೆ, ರೆಂಡರಿಂಗ್ ಗುಣಮಟ್ಟಕ್ಕೆ ಸಂಬಂಧವಿಲ್ಲದ ಮತ್ತು ಕೇವಲ ಕೋಆರ್ಡಿನೇಟ್ ಘೋಷಣೆಯ ಕೊರತೆಗೆ ಸಂಬಂಧಿಸಿದ ಲೇಔಟ್ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಲು ಗಂಟೆಗಟ್ಟಲೆ ಸಮಯ ವ್ಯರ್ಥವಾಗುತ್ತದೆ.
ಅದೃಶ್ಯ ಶಾಯಿ ಸಮಸ್ಯೆ (The Invisible Ink Problem)
ಎಮೋಜಿಗಳು ಇರಬೇಕಾದ ಜಾಗದಲ್ಲಿ ಬಿಳಿ ಚೌಕಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುವುದು ಒಂದು ಸರಳ ವಿಷಯವನ್ನು ತಿಳಿಸುತ್ತದೆ: ಪ್ರಸ್ತುತ ಫಾಂಟ್ ಆ ಭಾಷೆಯನ್ನು ಮಾತನಾಡುತ್ತಿಲ್ಲ (ಅಂದರೆ ಆ ಎಮೋಜಿಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತಿಲ್ಲ). Helvetica ಮತ್ತು ಇತರ ಪ್ರಮಾಣಿತ PDF ಫಾಂಟ್ಗಳು ಎಮೋಜಿಗಳ ವ್ಯಾಪಕ ಬಳಕೆಗೆ ಮುಂಚಿತವಾಗಿ ಬಂದವುಗಳಾಗಿವೆ. ಅವು ಎಮೋಜಿ Unicode ರೇಂಜ್ಗಳಿಗಾಗಿ ಗ್ಲಿಫ್ಗಳನ್ನು ಒಳಗೊಂಡಿಲ್ಲ, ಆದ್ದರಿಂದ iText ಆ ಕೋಡ್ ಪಾಯಿಂಟ್ಗಳನ್ನು ಕಂಡಾಗ ಏನನ್ನೂ ರೆಂಡರ್ ಮಾಡದೆ ಮುಂದೆ ಸಾಗುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ ದಾಖಲೆಯು ಖಾಲಿ ಬಾಕ್ಸ್ಗಳಿಂದ ತುಂಬಿರುತ್ತದೆ, ಇದು ಸೋಶಿಯಲ್ ಸೆಂಟಿಮೆಂಟ್ ವರದಿಗಳು ಅಥವಾ ಬಳಕೆದಾರರ ಪ್ರತಿಕ್ರಿಯೆಗಳ ಎಕ್ಸ್ಪೋರ್ಟ್ಗಳನ್ನು ಹಾಳಾದಂತೆ ಕಾಣುವಂತೆ ಮಾಡುತ್ತದೆ.
ಈ ಕೊರತೆಯನ್ನು ತುಂಬಲು ನೀವು ಕ್ಲೈಂಟ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಲು ಸಾಧ್ಯವಿಲ್ಲ. PDF ಗಳು ತಮ್ಮದೇ ಆದ ಫಾಂಟ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ ಮತ್ತು ಫೈಲ್ ಅನ್ನು ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಫಾಂಟ್ಗಳಿಂದ ಬೇರ್ಪಡಿಸಿದ ನಂತರ ಬ್ರೌಸರ್ನಲ್ಲಿ ಸರಿಯಾಗಿ ಕಾಣುವ ವಿಷಯವು ಯಾವುದೇ ಅರ್ಥವನ್ನು ನೀಡುವುದಿಲ್ಲ. ಇದಕ್ಕೆ ಪರಿಹಾರವೆಂದರೆ ಒಂದು ಸ್ಪಷ್ಟವಾದ ಫಾಂಟ್ ರೂಟಿಂಗ್ ಲೇಯರ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು. ಎಮೋಜಿ Unicode ಬ್ಲಾಕ್ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ Symbola ನಂತಹ ಮೀಸಲಾದ ಎಮೋಜಿ ಸಾಮರ್ಥ್ಯವಿರುವ ಫಾಂಟ್ ಅನ್ನು ನೋಂದಾಯಿಸಿ. ಕಪ್ಪು ಮತ್ತು ಬಿಳಿ ಹೃದಯ ಅಥವಾ ಎಚ್ಚರಿಕೆ ಚಿಹ್ನೆಯು ಹೊಳೆಯುವ ಬಣ್ಣದ ಗ್ಲಿಫ್ ಸೆಟ್ನಷ್ಟು ಸುಂದರವಾಗಿಲ್ಲದಿರಬಹುದು, ಆದರೆ ಅದು ಅರ್ಥವನ್ನು ತಿಳಿಸುತ್ತದೆ. ಖಾಲಿ ಆಯತক্ষেত্রವು ವೈಫಲ್ಯವನ್ನು ತಿಳಿಸುತ್ತದೆ. ಪೂರ್ಣ ಬಣ್ಣದ ಎಮೋಜಿ ಫಾಂಟ್ಗಳನ್ನು PDF ವೀಕ್ಷಕರಲ್ಲಿ ಸ್ಥಿರವಾಗಿ ರೆಂಡರ್ ಮಾಡುವುದು ಕಷ್ಟಕರವಾಗಿಯೇ ಉಳಿದಿದೆ ಮತ್ತು ಬಣ್ಣದ ಬೆಂಬಲಕ್ಕಾಗಿ ಪ್ರಯತ್ನಿಸುವುದು ಹೆಚ್ಚಾಗಿ ಪರಿಹಾರಕ್ಕಿಂತ ಹೆಚ್ಚು ಹೊಂದಾಣಿಕೆಯ ಸಮಸ್ಯೆಗಳನ್ನು (compatibility problems) ಉಂಟುಮಾಡುತ್ತದೆ.
iText ಲೈನ್ ಬ್ರೇಕಿಂಗ್ ಮೂಲಕ ಎರಡನೇ, ಹೆಚ್ಚು ಕಷ್ಟಕರವಾದ ಸಮಸ್ಯೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಲೈಬ್ರರಿಯು ಎಮೋಜಿ ಸರ್ೋಗೇಟ್ ಪೇರ್ಗಳನ್ನು (surrogate pairs) ತಪ್ಪಾದ ಗಡಿಯಲ್ಲಿ ವಿಭಜಿಸಬಹುದು, ಇದರಿಂದಾಗಿ ಒಂದು ಅಕ್ಷರವು ಎರಡು ಅಮಾನ್ಯ ಭಾಗಗಳಾಗಿ ಹರಿದುಹೋಗಬಹುದು. ಅದು ಸಂಭವಿಸಿದಾಗ, ಪಠ್ಯದ ಹರಿವು (text stream) ಹಾಳಾಗುತ್ತದೆ ಮತ್ತು ಒಂದು ಗ್ಲಿಫ್ ಇರಬೇಕಾದ ಜಾಗದಲ್ಲಿ ಓದಲಾಗದ ತುಣುಕುಗಳು ಉಳಿಯುತ್ತವೆ. ಇದನ್ನು ತಡೆಯಲು, ಸರ್ೋಗೇಟ್ ಪೇರ್ಗಳನ್ನು ಗುರುತಿಸುವ ಮತ್ತು ಅವುಗಳನ್ನು ಅಟಾಮಿಕ್ ಯುನಿಟ್ಗಳಾಗಿ (atomic units) ಪರಿಗಣಿಸುವ ಕಸ್ಟಮ್ ISplitCharacter ಅನ್ನು ಅಳವಡಿಸಿ. ಇದು ಲೇಔಟ್ ಇಂಜಿನ್ ಎಮೋಜಿಯ ಮಧ್ಯದಲ್ಲಿ ಲೈನ್ ಬ್ರೇಕ್ ಅನ್ನು ಸೇರಿಸದಂತೆ ತಡೆಯುತ್ತದೆ ಮತ್ತು ಪಠ್ಯದ ಸಮಗ್ರತೆಯನ್ನು ಕಾಪಾಡುತ್ತದೆ.
ಪಾರದರ್ಶಕತೆ ಕಪ್ಪು ಬಣ್ಣವಾಗಿ ಬದಲಾದಾಗ
ಮೃದುವಾದ rgba ಹಿನ್ನೆಲೆ ಅಥವಾ ಲೇಯರ್ಡ್ fill-opacity ಪರಿಣಾಮವಿರುವ SVG ಬ್ರೌಸರ್ನಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ. ಅದೇ ಮಾರ್ಕಪ್ ಅನ್ನು iText ಗೆ ನೀಡಿದಾಗ, ಪಾರದರ್ಶಕತೆಯು ಹೆಚ್ಚಾಗಿ ಘನ ಕಪ್ಪು ಆಯತವಾಗಿ ಬದಲಾಗುತ್ತದೆ. ಇಂಜಿನ್ CSS ಕಲರ್ ಫಂಕ್ಷನ್ಗಳು ಮತ್ತು opacity ಅಟ್ರಿಬ್ಯೂಟ್ಗಳನ್ನು ತಪ್ಪಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ, ಮತ್ತು opacity ಬದಲಿಗೆ ಪೂರ್ಣ ಸಾಂದ್ರತೆಯ ಶಾಯಿಯನ್ನು (full-density ink) ಬಳಸುತ್ತದೆ.
ಕನ್ವರ್ಟರ್ಗೆ ತಲುಪುವ ಮೊದಲು SVG ಅನ್ನು ಪ್ರಿ-ಪ್ರೊಸೆಸ್ ಮಾಡುವುದು ಏಕೈಕ ನಂಬಲರ್ಹವಾದ ರಕ್ಷಣೆಯಾಗಿದೆ. ಆಲ್ಫಾ ಬ್ಲೆಂಡಿಂಗ್ (alpha blending) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಯಾವುದೇ ಅಂಶವನ್ನು ತೆಗೆದುಹಾಕಿ ಅಥವಾ ಬದಲಾಯಿಸಿ. rgba() ಮೌಲ್ಯಗಳನ್ನು ಘನ rgb() ಬಣ್ಣಗಳಾಗಿ ಪರಿವರ್ತಿಸಿ. ನೀವು ಸ್ವಲ್ಪ ಮಟ್ಟಿನ ಅಪಾಸಿಟಿ (opacity) ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬೇಕೆಂದಿದ್ದರೆ, ಮೌಲ್ಯಗಳನ್ನು CSS shorthand ನಿಂದ ಹೊರತೆಗೆದು ಸ್ಟ್ಯಾಂಡರ್ಡ್ opacity ಅಟ್ರಿಬ್ಯೂಟ್ಗಳಿಗೆ ವರ್ಗಾಯಿಸಿ, ಆದರೆ ಪಾರದರ್ಶಕತೆಯನ್ನು (transparency) ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುವುದು ಅತ್ಯಂತ ಸುರಕ್ಷಿತವಾದ ಮಾರ್ಗವಾಗಿದೆ. ಈ ಬದಲಾವಣೆಗಳು ವೆಬ್ ವಿನ್ಯಾಸಕ್ಕೆ ಒಂದು ಹೆಜ್ಜೆ ಹಿಂದಕ್ಕೆ ಹೋಗಿದಂತೆ ಅನಿಸಬಹುದು, ಆದರೆ PDF ಆಧುನಿಕ CSS ಪಾರದರ್ಶಕತೆಗಿಂತ ಹಿಂದಿನ ವಿಭಿನ್ನ ಇಮೇಜಿಂಗ್ ಮಾಡೆಲ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಈ ಫಾರ್ಮ್ಯಾಟ್ವು ನಿಖರವಾದ ಬಣ್ಣದ ಮೌಲ್ಯಗಳನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಅಸ್ಪಷ್ಟ ಮೌಲ್ಯಗಳನ್ನು ನೀಡುವುದು ವಿಪತ್ತಿಗೆ ಕಾರಣವಾಗಬಹುದು.
ನೀವು ಮಾರ್ಕಪ್ ಅನ್ನು ಸ್ಯಾನಿಟೈಸ್ (sanitizing) ಮಾಡುವಾಗ, ಪ್ರತಿಯೊಂದು SVG ಕೂಡ ಸರಿಯಾದ xmlns ನೇಮ್ಸ್ಪೇಸ್ ಘೋಷಣೆಯನ್ನು (namespace declaration) ಹೊಂದಿದೆಯೇ ಎಂದು ಮತ್ತೊಮ್ಮೆ ಪರಿಶೀಲಿಸಿ. ಜನರೇಟ್ ಮಾಡಲಾದ HTML ಮತ್ತು ಟೆಂಪ್ಲೇಟ್ ಇಂಜಿನ್ಗಳು ಮಿನಿಫಿಕೇಶನ್ (minification) ಅಥವಾ DOM ಸೀರಿಯಲೈಸೇಶನ್ (serialization) ಸಮಯದಲ್ಲಿ ನೇಮ್ಸ್ಪೇಸ್ ಅಟ್ರಿಬ್ಯೂಟ್ಗಳನ್ನು ಆಗಾಗ್ಗೆ ಬಿಟ್ಟುಬಿಡುತ್ತವೆ. ಆ ನೇಮ್ಸ್ಪೇಸ್ ಇಲ್ಲದಿದ್ದರೆ, SVG ಪಾರ್ಸರ್ ಅಂಶಗಳನ್ನು ತಪ್ಪಾಗಿ ಗುರುತಿಸಬಹುದು ಅಥವಾ ಯಾವುದೇ ಎಚ್ಚರಿಕೆ ಇಲ್ಲದೆ ವಿಫಲವಾಗಬಹುದು, ಇದರಿಂದ ಪಾರ್ಸರ್ ಎರರ್ ಅಥವಾ ಪೇಜ್ಗೆ ತಲುಪದ ತಪ್ಪಾದ ವೆಕ್ಟರ್ ಡೇಟಾ ಉಂಟಾಗಬಹುದು. ಇದು ಕೇವಲ ಸೆಕೆಂಡುಗಳ ಕಾಲ ತೆಗೆದುಕೊಳ್ಳುವ ಮೂಲಭೂತ ಪರಿಶೀಲನೆಯಾಗಿದ್ದು, ಗಂಟೆಗಟ್ಟಲೆ ಸಮಯವನ್ನು ಉಳಿಸುತ್ತದೆ.
ಒಂದು ಟೆಂಪ್ಲೇಟ್, ಎರಡು ಲೋಕಗಳು
ಬ್ರೌಸರ್ ಮತ್ತು PDF ಗಾಗಿ ಪ್ರತ್ಯೇಕ HTML ಟೆಂಪ್ಲೇಟ್ಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ದೀರ್ಘಕಾಲದ ದೃಷ್ಟಿಯಿಂದ ಅತ್ಯಂತ ಕೆಟ್ಟ ಪರಿಹಾರವಾಗಿದೆ. ಲೇಬಲ್ಗಳು ಬದಲಾಗುತ್ತವೆ, ಮಾರ್ಜಿನ್ಗಳು ಬದಲಾಗುತ್ತವೆ ಮತ್ತು ಶೀಘ್ರದಲ್ಲೇ ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡಿದ ವರದಿ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ಆರ್ಕಿಟೆಕ್ಚರ್ ಒಂದೇ ಟೆಂಪ್ಲೇಟ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು context.isForPdf() ನಂತಹ ಒಂದೇ ಫ್ಲಾಗ್ (flag) ಮೂಲಕ ರೆಂಡರಿಂಗ್ ಲಾಜಿಕ್ ಅನ್ನು ವಿಭಜಿಸುತ್ತದೆ.
ಆ ಫ್ಲಾಗ್ false ಆಗಿದ್ದಾಗ, ಟೆಂಪ್ಲೇಟ್ ಪೂರ್ಣ ಬ್ರೌಸರ್ ಅನುಭವವನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಇನ್ಫಿನಿಟ್ ಜೂಮ್ (infinite zoom) ಗಾಗಿ ನೇಟಿವ್ SVG, ಆಧುನಿಕ CSS ಮತ್ತು ಬ್ರೌಸರ್ ಬೆಂಬಲಿಸುವ ಯಾವುದೇ ಬಣ್ಣದ ಅಸೆಟ್ಗಳನ್ನು (color assets) ಒದಗಿಸುತ್ತದೆ. ಫ್ಲಾಗ್ true ಆಗಿದ್ದಾಗ, ಅದೇ ಟೆಂಪ್ಲೇಟ್ SVG ಅಸೆಟ್ಗಳನ್ನು ಪ್ರಿ-ರೆಂಡರ್ಡ್ PNGಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತದೆ, ಎಮೋಜಿ-ಸುರಕ್ಷಿತ ಫಾಂಟ್ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಬೆಂಬಲವಿಲ್ಲದ ಯಾವುದೇ ಪಾರದರ್ಶಕತೆಯ ಪರಿಣಾಮಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಪಠ್ಯ ಮತ್ತು ರಚನೆಯು ಬದಲಾಗುವುದಿಲ್ಲ; ಕೇವಲ ಅಸೆಟ್ ಪೈಪ್ಲೈನ್ ಮತ್ತು ಸ್ಟೈಲಿಂಗ್ ನಿಯಮಗಳು ಗುರಿ ಮಾಧ್ಯಮಕ್ಕೆ (target medium) ಅನುಗುಣವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ.
ಈ ದ್ವಿ-ಮಾರ್ಗ ವಿಧಾನವು ಕೋಡ್ಬೇಸ್ ಅನ್ನು ಸುಸಜ್ಜಿತವಾಗಿಡುತ್ತದೆ. ನೀವು ಕೇವಲ ಒಂದು ಕಡೆ ವಿಷಯವನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಿದರೆ ಸಾಕು, ರೂಟಿಂಗ್ ಲೇಯರ್ ಸ್ಕ್ರೀನ್ ಮತ್ತು ಪೇಪರ್ ನಡುವಿನ ತಾಂತ್ರಿಕ ವ್ಯತ್ಯಾಸಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಪರೀಕ್ಷೆಯನ್ನು (testing) ಸರಳಗೊಳಿಸುತ್ತದೆ. ನೀವು ಪೂರ್ಣ ಡೆವಲಪರ್ ಟೂಲ್ಸ್ಗಳೊಂದಿಗೆ ಬ್ರೌಸರ್ನಲ್ಲಿ ಟೆಂಪ್ಲೇಟ್ ಲಾಜಿಕ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬಹುದು, ನಂತರ PDF ಫ್ಲಾಗ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡಿ, ಅದೇ ಡೇಟಾ ಕನ್ವರ್ಟರ್ ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡದೆ ಸ್ವಚ್ಛವಾದ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ನೀಡುತ್ತದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು.
PDF ಜನರೇಷನ್ ಬಗ್ಗೆ ಕಠಿಣ ಸತ್ಯ
PDF ಎಂದಿಗೂ ಬ್ರೌಸರ್ನಂತೆ ವರ್ತಿಸುವುದಿಲ್ಲ. ರೆಂಡರಿಂಗ್ ಮಾಡೆಲ್ಗಳು ಮೂಲಭೂತವಾಗಿ ಭಿನ್ನವಾಗಿವೆ ಮತ್ತು iText ನಂತಹ ಲೈಬ್ರರಿಗಳು ವೇಗ, ಫೈಲ್ ಗಾತ್ರ ಮತ್ತು ಸ್ಪೆಸಿಫಿಕೇಶನ್ ಅನುಸರಣೆಯ ನಡುವೆ ಉದ್ದೇಶಪೂರ್ವಕ ಸಮತೋಲನವನ್ನು (trade-offs) ಮಾಡುತ್ತವೆ. ಎಂಜಿನ್ ಜೊತೆ ಹೋರಾಡಿ ಉತ್ತಮದ ನಿರೀಕ್ಷೆ ಮಾಡುವುದರಿಂದ ಯಶಸ್ಸು ಸಿಗುವುದಿಲ್ಲ. ಅದು ಮಿತಿಗಳನ್ನು ಮೊದಲೇ ಒಪ್ಪಿಕೊಂಡು, ಅವುಗಳ ಸುತ್ತ ಪೈಪ್ಲೈನ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದರಿಂದ ಬರುತ್ತದೆ.
PDF ಹಂತಕ್ಕೆ ಮುನ್ನ ನಿಮ್ಮ ವೆಕ್ಟರ್ಗಳನ್ನು ಪರಿವರ್ತಿಸಿ. ಪ್ರತಿಯೊಂದು ಗ್ಲಿಫ್ (glyph) ಗೆ ಫಾಲ್ಬ್ಯಾಕ್ (fallback) ಇರುವಂತೆ ನಿಮ್ಮ ಫಾಂಟ್ಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ರೂಟ್ ಮಾಡಿ. ಪಾರದರ್ಶಕತೆಯನ್ನು ತೆಗೆದುಹಾಕಿ ಘನ ಬಣ್ಣಗಳಿಗೆ ಬದಲಾಯಿಸಿ. ನಿಮ್ಮ ಟೆಂಪ್ಲೇಟ್ಗಳು ಯಾವ ಲೋಕಕ್ಕಾಗಿ ರೆಂಡರ್ ಮಾಡಬೇಕೆಂದು ತಿಳಿಯಲು ಅಗತ್ಯವಿರುವ ಸಂದರ್ಭವನ್ನು (context) ನೀಡಿ. ಇದನ್ನು ಸ್ಥಿರವಾಗಿ ಮಾಡಿ, ಆಗ ನಿಮ್ಮ ಡಾಕ್ಯುಮೆಂಟ್ಗಳು ರೆಂಡರರ್ ಜೊತೆ ಹೋರಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ನೀವು ಉದ್ದೇಶಿಸಿದಂತೆಯೇ ಕಾಣಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ.