HTML ਨੂੰ PDF ਵਿੱਚ ਬਦਲਣਾ ਕਾਗਜ਼ੀ ਤੌਰ 'ਤੇ ਸੌਖਾ ਲੱਗਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਵਧੀਆ ਟੈਂਪਲੇਟ ਬਣਾਉਂਦੇ ਹੋ, ਆਪਣਾ ਡਾਟਾ ਪਾਉਂਦੇ ਹੋ, ਅਤੇ ਇੱਕ ਅਜਿਹੇ ਦਸਤਾਵੇਜ਼ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ ਜੋ ਵੈੱਬ ਪੇਜ ਦੀ ਹੂ-ਬ-ਹੂ ਨਕਲ ਕਰਦਾ ਹੋਵੇ। ਅਸਲ ਵਿੱਚ, ਇਹ ਪ੍ਰਕਿਰਿਆ ਅਕਸਰ ਕ੍ਰੈਸ਼ਾਂ, ਗਾਇਬ ਹੋਏ ਗਲੀਫਾਂ (glyphs) ਅਤੇ ਵਿਜ਼ੂਅਲ ਖਰਾਬੀ ਦੇ ਵਿਰੁੱਧ ਇੱਕ ਰੋਜ਼ਾਨਾ ਲੜਾਈ ਬਣ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਹਾਲੀਆ ਪ੍ਰੋਜੈਕਟ ਦੌਰਾਨ, ਤਿੰਨ ਸਮੱਸਿਆਵਾਂ ਵਾਰ-ਵਾਰ ਸਾਹਮਣੇ ਆ ਰਹੀਆਂ ਸਨ: ਜਦੋਂ iText ਕੁਝ ਖਾਸ SVG ਗ੍ਰਾਫਿਕਸ 'ਤੇ ਪਹੁੰਚਦਾ ਸੀ ਤਾਂ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਸੀ, ਇਮੋਜੀ (emojis) ਖਾਲੀ ਚਿੱਟੇ ਵਰਗਾਂ ਵਿੱਚ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਸਨ, ਅਤੇ ਬਾਰੀਕ ਟ੍ਰਾਂਸਪੇਰੈਂਟ ਬੈਕਗ੍ਰਾਊਂਡ ਅਚਾਨਕ ਗੂੜ੍ਹੇ ਕਾਲੇ ਬਲਾਕਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਸਨ। ਹਰ ਅਸਫਲਤਾ ਦਾ ਇੱਕ ਵੱਖਰਾ ਕਾਰਨ ਸੀ, ਅਤੇ ਇਹਨਾਂ ਤਿੰਨਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਇਸ ਗੱਲ 'ਤੇ ਮੁੜ ਵਿਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਸੀ ਕਿ ਐਪਲੀਕੇਸ਼ਨ PDF ਇੰਜਣ ਦੁਆਰਾ ਦੇਖੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਸਮੱਗਰੀ ਨੂੰ ਕਿਵੇਂ ਤਿਆਰ ਕਰਦੀ ਹੈ।
ਜਦੋਂ SVG ਪਾਈਪਲਾਈਨ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ
iText ਸਹੂਲਤ ਲਈ ਇੱਕ ਅੰਦਰੂਨੀ SVG ਰੈਂਡਰਰ (renderer) ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਇੱਕ ਗੰਭੀਰ ਕਮਜ਼ੋਰੀ ਨੂੰ ਛੁਪਾਉਂਦੀ ਹੈ। ਜਦੋਂ ਕਿਸੇ SVG ਵਿੱਚ ਗੁੰਝਲਦਾਰ ਪਾਥ (paths), ਭਾਰੀ CSS ਸਟਾਈਲਿੰਗ, ਜਾਂ ਕੁਝ ਖਾਸ ਕੋਆਰਡੀਨੇਟ ਟ੍ਰਾਂਸਫਾਰਮੇਸ਼ਨ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਇਨਬੈਡਡ ਪਾਰਸਰ (parser) ਕੋਈ ਸਾਫ਼ ਐਕਸੈਪਸ਼ਨ (exception) ਦੇ ਕੇ ਅੱਗੇ ਨਹੀਂ ਵਧਦਾ। ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਪੂਰੇ ਸਿਸਟਮ ਕ੍ਰੈਸ਼ ਹੁੰਦੇ ਹਨ ਜੋ ਬਿਨਾਂ ਕਿਸੇ ਚੇਤਾਵਨੀ ਦੇ PDF ਜਨਰੇਸ਼ਨ ਥ੍ਰੈਡ (thread) ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਅਧੂਰੀ ਫਾਈਲ ਅਤੇ ਵੈਕਟਰ ਪਾਰਸਰ ਦੇ ਅੰਦਰ ਕਿਤੇ ਡੂੰਘੇ ਇਸ਼ਾਰੇ ਵਾਲਾ ਸਟੈਕ ਟ੍ਰੇਸ (stack trace) ਬਚਦਾ ਹੈ।
ਭਰੋਸੇਯੋਗ ਹੱਲ ਇਹ ਹੈ ਕਿ iText ਨੂੰ SVG ਰੈਂਡਰ ਕਰਨ ਲਈ ਕਹਿਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਜਾਵੇ। ਇਸ ਦੀ ਬਜਾਏ, ਉਸ ਕੰਮ ਨੂੰ ਸਟੈਂਡਅਲੋਨ ਮੋਡ ਵਿੱਚ ਚੱਲ ਰਹੇ Apache Batik ਨੂੰ ਸੌਂਪ ਦਿਓ। Batik ਉਹੀ ਗੁੰਝਲਦਾਰ ਪਾਥ ਅਤੇ CSS ਨਿਯਮਾਂ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਅਸਥਿਰਤਾ ਦੇ ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਵੱਖ ਰੱਖਣ ਨਾਲ ਤੁਹਾਡਾ PDF ਇੰਜਣ ਗ੍ਰਾਫਿਕਸ ਨਾਲ ਸਬੰਧਤ ਅਸਥਿਰਤਾ ਤੋਂ ਬਚਿਆ ਰਹਿੰਦਾ ਹੈ। ਵਰਕਫਲੋ ਸਿੱਧਾ ਹੈ: ਦਸਤਾਵੇਜ਼ ਦੀ ਅਸੈਂਬਲੀ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, PNG ਡਾਟਾ URL ਬਣਾਉਣ ਲਈ SVG ਨੂੰ Batik ਰਾਹੀਂ ਚਲਾਓ। ਕੱਚੇ ਵੈਕਟਰ ਮਾਰਕਅੱਪ (vector markup) ਦੀ ਬਜਾਏ ਉਸ ਰਾਸਟਰ (raster) ਚਿੱਤਰ ਨੂੰ iText ਵਿੱਚ ਪਾਸ ਕਰੋ। ਸਟੈਂਡਅਲੋਨ Batik, ਇੱਕ ਵੱਡੀ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਅੰਦਰ ਬੰਦ ਅਤੇ ਫ੍ਰੀਜ਼ ਕੀਤੇ ਇਨਬੈਡਡ ਰੈਂਡਰਰ ਦੇ ਮੁਕਾਬਲੇ SVG ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਨੂੰ ਵਧੇਰੇ ਨੇੜਿਓਂ ਟ੍ਰੈਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਅਲਗ ਰੱਖਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਖਰਾਬ ਗ੍ਰਾਫਿਕ ਪੂਰੀ ਦਸਤਾਵੇਜ਼ ਕਨਵਰਸ਼ਨ ਨੂੰ ਖਰਾਬ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਵੇਰਵਾ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਚਾਰਟ ਪੇਸ਼ੇਵਰ ਲੱਗਦਾ ਹੈ ਜਾਂ ਕਿਸੇ ਬੱਗ ਰਿਪੋਰਟ ਵਾਂਗ। SVG ਆਪਣੇ ਕੋਆਰਡੀਨੇਟ ਸਿਸਟਮ ਅਤੇ ਸਕੈਲਿੰਗ ਵਿਵਹਾਰ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ viewBox ਐਟਰੀਬਿਊਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਕਨਵਰਸ਼ਨ ਕੋਡ viewBox ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਬਿਲਕੁਲ ਸਹੀ ਚਾਰਟ ਪੜ੍ਹਨ ਅਯੋਗ ਬਿੰਦੂ ਤੱਕ ਸੁੰਗੜ ਸਕਦਾ ਹੈ ਜਾਂ ਵਿਗਾੜਿਆ ਹੋਇਆ ਮੈੱਸ ਬਣ ਸਕਦਾ ਹੈ। ਇਸ ਐਟਰੀਬਿਊਟ ਨੂੰ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਪਾਰਸ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਡਾਇਮੈਂਸ਼ਨਾਂ ਨੂੰ ਆਪਣੇ ਆਉਟਪੁੱਟ ਸਾਈਜ਼ ਨਾਲ ਮੈਪ ਕਰੋ। ਇਸ ਕਦਮ ਨੂੰ ਛੱਡਣ ਨਾਲ ਲੇਆਉਟ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਕਈ ਘੰਟੇ ਬਰਬਾਦ ਹੋ ਸਕਦੇ ਹਨ, ਜਿਸਦਾ ਰੈਂਡਰਿੰਗ ਕੁਆਲਿਟੀ ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਗਾਇਬ ਕੋਆਰਡੀਨੇਟ ਡਿਕਲੇਰੇਸ਼ਨ ਕਾਰਨ ਹੁੰਦਾ ਹੈ।
ਅਦਿੱਖ ਸਿਆਹੀ ਦੀ ਸਮੱਸਿਆ
ਜਿੱਥੇ ਇਮੋਜੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਉੱਥੇ ਖਾਲੀ ਵਰਗ ਹੋਣਾ ਇੱਕ ਸਧਾਰਨ ਕਹਾਣੀ ਦੱਸਦਾ ਹੈ: ਮੌਜੂਦਾ ਫੋਂਟ ਉਹ ਭਾਸ਼ਾ ਨਹੀਂ ਜਾਣਦਾ। Helvetica ਅਤੇ ਹੋਰ ਸਟੈਂਡਰਡ PDF ਫੋਂਟ ਇਮੋਜੀ ਦੀ ਵਿਆਪਕ ਵਰਤੋਂ ਤੋਂ ਪਹਿਲਾਂ ਦੇ ਹਨ। ਉਹਨਾਂ ਵਿੱਚ ਇਮੋਜੀ Unicode ਰੇਂਜਾਂ ਲਈ ਗਲੀਫ (glyphs) ਸ਼ਾਮਲ ਨਹੀਂ ਹਨ, ਇਸ ਲਈ ਜਦੋਂ iText ਉਹਨਾਂ ਕੋਡ ਪੁਆਇੰਟਾਂ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਕੁਝ ਵੀ ਰੈਂਡਰ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਅੱਗੇ ਵਧ ਜਾਂਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ ਇੱਕ ਅਜਿਹਾ ਦਸਤਾਵੇਜ਼ ਮਿਲਦਾ ਹੈ ਜੋ ਖਾਲੀ ਡੱਬਿਆਂ ਨਾਲ ਭਰਿਆ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸੋਸ਼ਲ ਸੈਂਟੀਮੈਂਟ ਰਿਪੋਰਟਾਂ ਜਾਂ ਯੂਜ਼ਰ ਫੀਡਬੈਕ ਐਕਸਪੋਰਟ ਖਰਾਬ ਲ
ਕਨਵਰਟਰ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ SVG ਦੀ ਪ੍ਰੀ-ਪ੍ਰੋਸੈਸਿੰਗ (pre-processing) ਹੀ ਇੱਕੋ-ਇੱਕ ਭਰੋਸੇਯੋਗ ਰੱਖਿਆ ਹੈ। ਅਲਫਾ ਬਲੈਂਡਿੰਗ (alpha blending) 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ ਐਲੀਮੈਂਟ ਨੂੰ ਹਟਾ ਦਿਓ ਜਾਂ ਬਦਲ ਦਿਓ। rgba() ਮੁੱਲਾਂ ਨੂੰ ਸੋਲਿਡ rgb() ਰੰਗਾਂ ਵਿੱਚ ਬਦਲੋ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਓਪੈਸਿਟੀ (opacity) ਦਾ ਕੁਝ ਹਿੱਸਾ ਰੱਖਣਾ ਹੀ ਹੈ, ਤਾਂ ਮੁੱਲਾਂ ਨੂੰ CSS ਸ਼ਾਰਟਹੈਂਡ ਤੋਂ ਕੱਢ ਕੇ ਸਟੈਂਡਰਡ ਓਪੈਸਿਟੀ ਐਟਰੀਬਿਊਟਸ (standard opacity attributes) ਵਿੱਚ ਪਾ ਦਿਓ, ਹਾਲਾਂਕਿ ਟ੍ਰਾਂਸਪੇਰੈਂਸੀ (transparency) ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦੇਣਾ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਹੈ। ਇਹ ਤਬਦੀਲੀਆਂ ਵੈੱਬ ਡਿਜ਼ਾਈਨ ਲਈ ਇੱਕ ਕਦਮ ਪਿੱਛੇ ਜਾਣ ਵਾਂਗ ਲੱਗਦੀਆਂ ਹਨ, ਪਰ PDF ਇੱਕ ਵੱਖਰੇ ਇਮੇਜਿੰਗ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜੋ ਆਧੁਨਿਕ CSS ਟ੍ਰਾਂਸਪੇਰੈਂਸੀ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਹੈ। ਇਹ ਫਾਰਮੈਟ ਸਪੱਸ਼ਟ ਰੰਗ ਮੁੱਲਾਂ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਅਸਪਸ਼ਟ ਮੁੱਲ ਦੇਣਾ ਮੁਸੀਬਤ ਨੂੰ ਸੱਦਾ ਦੇਣਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਮਾਰਕਅੱਪ (markup) ਨੂੰ ਸਾਫ਼ ਕਰ ਰਹੇ ਹੋਵੋ, ਤਾਂ ਇਹ ਦੋਹਰਾ ਚੈੱਕ ਕਰੋ ਕਿ ਹਰ SVG ਵਿੱਚ ਸਹੀ xmlns ਨਾਮਸਪੇਸ ਡਿਕਲੇਰੇਸ਼ਨ (namespace declaration) ਹੈ। ਬਣਾਈ ਗਈ HTML ਅਤੇ ਟੈਂਪਲੇਟ ਇੰਜਣ ਅਕਸਰ ਮਿਨੀਫਿਕੇਸ਼ਨ (minification) ਜਾਂ DOM ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ (serialization) ਦੌਰਾਨ ਨਾਮਸਪੇਸ ਐਟਰੀਬਿਊਟਸ ਨੂੰ ਹਟਾ ਦਿੰਦੇ ਹਨ। ਉਸ ਨਾਮਸਪੇਸ ਤੋਂ ਬਿਨਾਂ, SVG ਪਾਰਸਰ ਐਲੀਮੈਂਟਸ ਦੀ ਗਲਤ ਪਛਾਣ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਚੁੱਪਚਾਪ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਜਾਂ ਤਾਂ ਪਾਰਸਰ ਐਰਰ ਆਉਂਦਾ ਹੈ ਜਾਂ ਖਰਾਬ ਵੈਕਟਰ ਡੇਟਾ ਬਣਦਾ ਹੈ ਜੋ ਕਦੇ ਵੀ ਪੇਜ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਇਹ ਇੱਕ ਬੁਨਿਆਦੀ ਚੈੱਕ ਹੈ ਜੋ ਸਿਰਫ਼ ਕੁਝ ਸਕਿੰਟਾਂ ਦਾ ਸਮਾਂ ਲੈਂਦਾ ਹੈ ਅਤੇ ਕਈ ਘੰਟਿਆਂ ਦੀ ਬਚਤ ਕਰਦਾ ਹੈ।
ਇੱਕ ਟੈਂਪਲੇਟ, ਦੋ ਦੁਨੀਆਵਾਂ
ਸਭ ਤੋਂ ਮਾੜਾ ਲੰਬੇ ਸਮੇਂ ਦਾ ਹੱਲ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ PDF ਲਈ ਵੱਖਰੇ HTML ਟੈਂਪਲੇਟ ਰੱਖਣਾ ਹੈ। ਲੇਬਲ ਬਦਲ ਜਾਂਦੇ ਹਨ, ਮਾਰਜਿਨ ਬਦਲ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜਲਦੀ ਹੀ ਐਕਸਪੋਰਟ ਕੀਤੀ ਰਿਪੋਰਟ ਡੈਸ਼ਬੋਰਡ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ। ਇੱਕ ਸਾਫ਼ ਆਰਕੀਟੈਕਚਰ ਇੱਕ ਸਿੰਗਲ ਟੈਂਪਲੇਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਫਲੈਗ (flag) ਨਾਲ ਰੈਂਡਰਿੰਗ ਲੌਜਿਕ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ context.isForPdf()।
ਜਦੋਂ ਉਹ ਫਲੈਗ false ਹੁੰਦਾ ਹੈ, ਤਾਂ ਟੈਂਪਲੇਟ ਪੂਰਾ ਬ੍ਰਾਊਜ਼ਰ ਅਨੁਭਵ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਇਨਫੀਨੀਟ ਜ਼ੂਮ (infinite zoom) ਲਈ ਨੇਟਿਵ SVG, ਆਧੁਨਿਕ CSS, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਦੁਆਰਾ ਸਮਰਥਿਤ ਰੰਗ ਐਸੇਟਸ (color assets) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਫਲੈਗ true ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਹੀ ਟੈਂਪਲੇਟ SVG ਐਸੇਟਸ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਰੈਂਡਰ ਕੀਤੇ PNGs ਨਾਲ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਇਮੋਜੀ-ਸੁਰੱਖਿਅਤ ਫੌਂਟ ਸਟੈਕ (emoji-safe font stack) ਨੂੰ ਐਕਟੀਵੇਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਅਸਮਰਥਿਤ ਟ੍ਰਾਂਸਪੇਰੈਂਸੀ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਟੈਕਸਟ ਅਤੇ ਢਾਂਚਾ ਬਦਲਿਆ ਨਹੀਂ ਜਾਂਦਾ; ਸਿਰਫ਼ ਐਸੇਟ ਪਾਈਪਲਾਈਨ ਅਤੇ ਸਟਾਈਲਿੰਗ ਨਿਯਮ ਹੀ ਟਾਰਗੇਟ ਮੀਡੀਅਮ ਅਨੁਸਾਰ ਅਨੁਕੂਲਿਤ ਹੁੰਦੇ ਹਨ।
ਇਹ ਦੋਹਰਾ-ਰਾਹ (dual-path) ਅਪ੍ਰੋਚ ਕੋਡਬੇਸ ਨੂੰ ਸਹੀ ਰੱਖਦੀ ਹੈ। ਤੁਸੀਂ ਇੱਕੋ ਜਗ੍ਹਾ 'ਤੇ ਕੰਟੈਂਟ ਅਪਡੇਟ ਕਰਦੇ ਹੋ, ਅਤੇ ਰੂਟਿੰਗ ਲੇਅਰ ਸਕ੍ਰੀਨ ਅਤੇ ਕਾਗਜ਼ ਵਿਚਕਾਰ ਮਕੈਨੀਕਲ ਅੰਤਰਾਂ ਨੂੰ ਸੰਭਾਲਦੀ ਹੈ। ਇਹ ਟੈਸਟਿੰਗ ਨੂੰ ਵੀ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਪੂਰੇ ਡਿਵੈਲਪਰ ਟੂਲਜ਼ ਦੇ ਨਾਲ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਟੈਂਪਲੇਟ ਲੌਜਿਕ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ PDF ਫਲੈਗ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਉਹੀ ਡੇਟਾ ਕਨਵਰਟਰ ਨੂੰ ਕ੍ਰੈਸ਼ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਸਾਫ਼ ਦਸਤਾਵੇਜ਼ ਤਿਆਰ ਕਰਦਾ ਹੈ।
PDF ਜਨਰੇਸ਼ਨ ਬਾਰੇ ਕੌੜਾ ਸੱਚ
PDF ਕਦੇ ਵੀ ਬ੍ਰਾਊਜ਼ਰ ਵਾਂਗ ਵਿਵਹਾਰ ਨਹੀਂ ਕਰੇਗਾ। ਰੈਂਡਰਿੰਗ ਮਾਡਲ ਮੂਲ ਰੂਪ ਵਿੱਚ ਵੱਖਰੇ ਹਨ, ਅਤੇ iText ਵਰਗੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਸਪੀਡ, ਫਾਈਲ ਸਾਈਜ਼ ਅਤੇ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੀ ਪਾਲਣਾ ਵਿਚਕਾਰ ਜਾਣਬੁੱਝ ਕੇ ਸਮਝੌਤੇ ਕਰਦੀਆਂ ਹਨ। ਸਫਲਤਾ ਇੰਜਣ ਨਾਲ ਲੜਨ ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਦੀ ਉਮੀਦ ਕਰਨ ਤੋਂ ਨਹੀਂ ਮਿਲਦੀ। ਇਹ ਸੀਮਾਵਾਂ ਨੂੰ ਜਲਦੀ ਸਵੀਕਾਰ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਪਾਈਪਲਾਈਨ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਮਿਲਦੀ ਹੈ।
PDF ਪੜਾਅ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਵੈਕਟਰਾਂ ਨੂੰ ਬਦਲੋ। ਆਪਣੇ ਫੌਂਟਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਰੂਟ ਕਰੋ ਤਾਂ ਜੋ ਹਰ ਗਲੀਫ (glyph) ਕੋਲ ਫਾਲਬੈਕ (fallback) ਹੋਵੇ। ਟ੍ਰਾਂਸਪੇਰੈਂਸੀ ਨੂੰ ਹਟਾ ਕੇ ਸੋਲਿਡ ਰੰਗਾਂ ਵਿੱਚ ਬਦਲੋ। ਆਪਣੇ ਟੈਂਪਲੇਟਸ ਨੂੰ ਉਹ ਸੰਦਰਭ (context) ਦਿਓ ਜਿਸਦੀ ਉਹਨਾਂ ਨੂੰ ਇਹ ਜਾਣਨ ਲਈ ਲੋੜ ਹੈ ਕਿ ਉਹ ਕਿਸ ਦੁਨੀਆ ਲਈ ਰੈਂਡਰ ਕਰ ਰਹੇ ਹਨ। ਇਹ ਲਗਾਤਾਰ ਕਰੋ, ਅਤੇ ਤੁਹਾਡੇ ਦਸਤਾਵੇਜ਼ ਰੈਂਡਰਰ ਨਾਲ ਲੜਨਾ ਬੰਦ ਕਰ ਦੇਣਗੇ ਅਤੇ ਬਿਲਕੁਲ ਉਵੇਂ ਹੀ ਦਿਖਣਗੇ ਜਿਵੇਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਸੀ।