उपयोगकर्ता मार्गदर्शिका

Glasswall Conform को आगे की प्रोसेसिंग के लिए मानकों को पूरा करने हेतु PDF फ़ाइलों का पूर्व-प्रसंस्करण करने के लिए डिज़ाइन किया गया है। यह दृश्य सामग्री को निकालता और पुनर्निर्मित करता है, और पूर्ण Content Disarm and Reconstruction (CDR) सुरक्षा के लिए इसे Glasswall Embedded Engine के साथ उपयोग किया जाना चाहिए।

यह दस्तावेज़ PDF दस्तावेज़ों के पुनर्निर्माण के लिए Conform का उपयोग करने के निर्देश प्रदान करता है, साथ ही कमांड-लाइन टूल को चलाने के कई उदाहरण भी देता है।

स्थापना

Conform एक system-wide कमांड के रूप में इंस्टॉल होता है, जिसे आपके terminal से एक्सेस किया जा सकता है।

इंस्टॉल होने के बाद, glasswall_conform कमांड आपके सिस्टम PATH पर उपलब्ध होगी। इस परिवर्तन के प्रभावी होने के लिए आपको अपना terminal session पुनः आरंभ करना पड़ सकता है।

Windows

Windows के लिए Conform को .exe installer के रूप में वितरित किया जाता है। यह C:\Program Files (x86)\Glasswall Conform में इंस्टॉल होता है और इस फ़ोल्डर को आपके सिस्टम PATH में जोड़ता है।

Installer चलाकर और निर्देशों का पालन करके Conform इंस्टॉल करें:

.\glasswall-conform-1.1.0.exe

या automation या CI environments के लिए इसे silent mode में इंस्टॉल करें:

.\glasswall-conform-1.1.0.exe /VERYSILENT

Linux

Linux के लिए Conform को .rpm और .deb दोनों packages के रूप में वितरित किया जाता है।

दोनों /opt/glasswall_conform में फ़ाइलें इंस्टॉल करते हैं और /usr/local/bin में एक symbolic link बनाते हैं, ताकि कमांड लाइन से glasswall_conform चलाया जा सके।

RPM (उदा. Rocky 9, Rocky 8)

sudo yum -y install ./glasswall_conform-1.1.0-1.x86_64.rpm

DEB (उदा. Ubuntu 24.04, Ubuntu 22.04)

sudo apt-get -y install ./glasswall-conform_1.1.0_amd64.deb

सेटअप

glasswall_conform को कॉल करने से पहले, सुनिश्चित करें कि आपका environment सही तरीके से सेट अप है।

उन modes के लिए जो Embedded Engine का उपयोग करते हैं, --library-directory को पास की गई directory में Embedded Engine binaries होनी चाहिए। Conform स्टार्टअप पर इसकी पुष्टि करता है और यदि वे मौजूद नहीं हैं तो एक छोटा संदेश देकर रुक जाता है।

Linux

उन processing modes के लिए जो Embedded Engine का उपयोग करते हैं, LD_LIBRARY_PATH को इस तरह सेट किया जाना चाहिए कि उसमें Embedded Engine वाली directory शामिल हो। उदाहरण के लिए, यदि Embedded Engine path /home/azureuser/glasswall/Release-16.2.0 पर है, तो आप अस्थायी रूप से LD_LIBRARY_PATH को संशोधित कर सकते हैं:

export LD_LIBRARY_PATH=/home/azureuser/glasswall/Release-16.2.0:$LD_LIBRARY_PATH

Ubuntu

Ubuntu-आधारित systems पर, यदि आपको libgthread-2.0.so.0: cannot open shared object file: No such file or directory त्रुटि संदेश मिलता है, तो आप निम्न कमांड से आवश्यक package इंस्टॉल करके इसे हल कर सकते हैं:

DEBIAN_FRONTEND=noninteractive && apt update && apt install -y libglib2.0-0

Windows

हम chocolatey का उपयोग करके Windows dependencies इंस्टॉल करने की सिफारिश करते हैं।

सभी processing modes के लिए, Microsoft Visual C++ Redistributable इंस्टॉल होना चाहिए।

उन processing modes के लिए जो Embedded Engine का उपयोग करते हैं:

PATH को Embedded Engine वाली डायरेक्टरी को शामिल करने के लिए सेट किया जाना चाहिए। उदाहरण के लिए, यदि Embedded Engine पथ C:/glasswall/Release-16.2.0 पर है, तो आप अस्थायी रूप से PATH को संशोधित कर सकते हैं:
```
SET "PATH=%PATH%;C:/glasswall/Release-16.2.0"
```
OpenSSL light या OpenSSL इंस्टॉल होना चाहिए।

chocolatey का उपयोग करके vcredist140 और openssl.light की उदाहरण Windows docker इंस्टॉलेशन:

# escape=`
FROM mcr.microsoft.com/windows/servercore:ltsc2022

USER ContainerAdministrator
WORKDIR C:\temp\
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]

# Download and install Chocolatey, to install OpenSSL and Visual C++ Redistributable
RUN Invoke-WebRequest -Uri 'https://chocolatey.org/install.ps1' -OutFile 'install.ps1'; `
    ./install.ps1; ` 
    Remove-Item install.ps1; `
    Import-Module "$env:ChocolateyInstall/helpers/chocolateyProfile.psm1"; `
    choco install -y --fail-on-unfound --no-progress --stop-on-first-package-failure vcredist140; `
    choco install -y --fail-on-unfound --no-progress --stop-on-first-package-failure openssl.light;

लाइसेंसिंग

Glasswall Conform को संचालित होने के लिए एक वैध license की आवश्यकता होती है। license file प्राप्त करने के लिए, [email protected] से संपर्क करें।

--license argument का उपयोग सभी processing modes में license file के सीधे path, या gwkey.lic file वाली डायरेक्टरी के path को निर्दिष्ट करने के लिए किया जा सकता है।

Engine modes (engine, engine_memory): --license वैकल्पिक है। यदि इसे निर्दिष्ट नहीं किया गया है, तो Conform स्वचालित रूप से --library-directory में gwkey.lic file खोजेगा। यदि file मिल जाती है, तो उसे license के रूप में उपयोग किया जाता है। यदि नहीं मिलती, तो एक error उत्पन्न होती है।
Conform-only modes (conform_only, conform_only_memory): --license आवश्यक है, क्योंकि खोजने के लिए कोई library directory नहीं होती।

यदि license अनुपस्थित है, अमान्य है, या उसमें आवश्यक entitlements शामिल नहीं हैं, तो Conform error code 2 के साथ बाहर निकल जाएगा।

  --license LICENSE      Path to the Glasswall Conform license file, or a directory containing 'gwkey.lic'.
                         Required for conform_only and conform_only_memory modes.
                         In engine modes, defaults to 'gwkey.lic' in the library directory if not specified.

Processing modes

Conform को command line से चलाया जाता है और यह files को process करने के लिए कई processing modes प्रदान करता है। glasswall_conform को कॉल करते समय, पहला positional argument processing mode को निर्दिष्ट करता है। उपलब्ध processing modes हैं:

engine: Engine का उपयोग करके files को सुरक्षित करता है। non-conforming files को Conform द्वारा reconstruct किया जाता है और फिर Engine द्वारा process किया जाता है।
conform_only: केवल Conform का उपयोग करके files को reconstruct करता है, बिना CDR protection प्रदान किए।
engine_memory: standard input के माध्यम से base64-encoded file स्वीकार करता है। Engine का उपयोग करके memory में एक single file को सुरक्षित करता है। यदि file non-conforming है, तो उसे Conform का उपयोग करके reconstruct किया जाता है और फिर Engine द्वारा process किया जाता है। processed file standard output के माध्यम से लौटाई जाती है, या standard error के माध्यम से एक error लौटाई जाती है।
conform_only_memory: standard input के माध्यम से base64-encoded फ़ाइल स्वीकार करता है। केवल Conform का उपयोग करके एकल फ़ाइल का पुनर्निर्माण करता है, बिना CDR सुरक्षा प्रदान किए। पुनर्निर्मित फ़ाइल standard output के माध्यम से लौटाई जाती है, या standard error के माध्यम से एक त्रुटि लौटाई जाती है।

उपलब्ध processing modes दिखाने के लिए:

glasswall_conform -h

engine

यह processing mode अभिप्रेत default है और Glasswall CDR तकनीक का उपयोग करके फ़ाइलों को साफ़ करता है। इसके लिए Embedded Engine तक पहुँच और एक वैध licence आवश्यक है।

इस processing mode को invoke करने के उदाहरण के लिए, देखें: End to end protection.

प्रोसेस की गई फ़ाइलों को तीन output subdirectories में से किसी एक में क्रमबद्ध किया जाता है:

01_engine_success: वे फ़ाइलें जिन्हें Conform द्वारा पुनर्निर्माण की आवश्यकता के बिना Embedded Engine ने सफलतापूर्वक प्रोसेस किया।
02_conform_engine_success: PDF फ़ाइलें जिन्हें प्रारंभ में Embedded Engine प्रोसेस नहीं कर सका, लेकिन जिन्हें Conform द्वारा पुनर्निर्मित किया गया और फिर Embedded Engine ने सफलतापूर्वक प्रोसेस किया।
03_failure: वे फ़ाइलें जिन्हें Embedded Engine और Conform दोनों का उपयोग करके प्रोसेस नहीं किया जा सका, या जिनमें ऐसी सामग्री है जिसे custom content management policy का उपयोग करके disallow पर सेट किया गया है।

engine processing mode के लिए command line arguments दिखाने के लिए:

glasswall_conform engine -h

conform_only

यह processing mode Embedded Engine का उपयोग किए बिना फ़ाइलों का पुनर्निर्माण करता है। यह CDR सुरक्षा प्रदान नहीं करता।

इस processing mode को invoke करने के उदाहरण के लिए, देखें: CDR सुरक्षा के बिना फ़ाइलों का पुनर्निर्माण

प्रोसेस की गई फ़ाइलों को दो output subdirectories में से किसी एक में क्रमबद्ध किया जाता है:

01_conform_success: Conform द्वारा सफलतापूर्वक पुनर्निर्मित की गई फ़ाइलें।
02_failure: वे फ़ाइलें जिनका Conform द्वारा पुनर्निर्माण नहीं हो सका।

conform_only processing mode के लिए command line arguments दिखाने हेतु:

glasswall_conform conform_only -h

engine_memory

यह मोड standard input के माध्यम से base64-encoded फ़ाइल स्वीकार करता है और उसे Embedded Engine का उपयोग करके प्रोसेस करता है। यदि फ़ाइल non-conforming है, तो उसे Conform द्वारा reconstruct किया जाता है, फिर Engine द्वारा प्रोसेस किया जाता है। अंतिम आउटपुट standard output के माध्यम से लौटाया जाता है, या standard error के माध्यम से एक त्रुटि लौटाई जाती है। कोई भी फ़ाइल disk पर नहीं लिखी जाती।

यह मोड उन सिस्टम्स के साथ एकीकरण के लिए आदर्श है जो फ़ाइलों को memory में रखते हैं और filesystem input या output पर निर्भर नहीं करते।

इस processing mode को invoke करने के उदाहरण के लिए, देखें: डिस्क से पढ़े या डिस्क पर लिखे बिना memory में फ़ाइलों को प्रोसेस करना.

engine_memory processing mode के लिए command line arguments दिखाने हेतु:

glasswall_conform engine_memory -h

--file-name optional argument का उपयोग in-memory फ़ाइल का नाम निर्दिष्ट करने के लिए किया जा सकता है। इसका उपयोग logs और post processing summary लिखते समय किया जाता है, और यदि निर्दिष्ट न किया गया हो तो यह base64 encoded data के पहले 8 characters को default के रूप में उपयोग करता है।

conform_only_memory

यह मोड standard input के माध्यम से base64-encoded फ़ाइल स्वीकार करता है और केवल Conform का उपयोग करके उसे reconstruct करता है (CDR protection के बिना)। reconstructed फ़ाइल standard output के माध्यम से लौटाई जाती है, या standard error के माध्यम से एक त्रुटि लौटाई जाती है। कोई भी फ़ाइल disk पर नहीं लिखी जाती।

conform_only_memory processing mode के लिए command line arguments दिखाने हेतु:

glasswall_conform conform_only_memory -h

परीक्षण

Conform का मूल्यांकन करने के लिए PDF परीक्षण फ़ाइलों का एक डेटासेट अनुरोध पर उपलब्ध है। Kiteworks के माध्यम से परीक्षण फ़ाइलों तक पहुँच का अनुरोध करने के लिए कृपया हमसे संपर्क करें।

उदाहरण

Examples

एंड-टू-एंड सुरक्षा

यह उदाहरण engine processing mode का उसके सबसे बुनियादी स्तर पर उपयोग दिखाता है।

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0

उदाहरण input directory:

/home/azureuser/input_files
    conforming_docx.docx
    conforming_pdf.pdf
    corrupt_docx.docx
    nonconforming_pdf.pdf
    unsupported_filetype.txt

processing के बाद उदाहरण output directory:

/home/azureuser/output_files
├───01_engine_success
│       conforming_docx.docx
│       conforming_pdf.pdf
│
├───02_conform_engine_success
│       nonconforming_pdf.pdf
│
└───03_failure
        corrupt_docx.docx
        unsupported_filetype.txt

ध्यान दें कि subdirectory नामों को निम्न arguments का उपयोग करके अनुकूलित किया जा सकता है:

--engine-success-path: वैकल्पिक। उन files के लिए output subdirectory नाम जिन्हें Embedded Engine द्वारा Conform के reconstruction की आवश्यकता के बिना सफलतापूर्वक process किया गया। Default 01_engine_success
--conform-success-path: वैकल्पिक। उन files के लिए output subdirectory नाम जिन्हें प्रारंभ में Embedded Engine द्वारा process नहीं किया जा सका, लेकिन Conform द्वारा reconstruct किया गया और फिर Embedded Engine द्वारा सफलतापूर्वक process किया गया। Default 02_conform_engine_success
--failure-path: वैकल्पिक। उन files के लिए output subdirectory नाम जिन्हें Embedded Engine और Conform दोनों का उपयोग करके process नहीं किया जा सका। Default 03_failure

यदि यह वांछित हो कि सभी सफलतापूर्वक सुरक्षित की गई files एक ही output directory में लिखी जाएँ, चाहे file को reconstruct करने के लिए Conform का उपयोग किया गया हो या नहीं, तो आप files को उसी success subdirectory path में लिखने के लिए निर्दिष्ट कर सकते हैं। उदाहरण के लिए:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --engine-success-path success --conform-success-path success --failure-path failure

processing के बाद उदाहरण संक्षिप्त terminal output:

Glasswall Conform processed 3/5 files (60.00%)
Glasswall Conform failed to process 2/5 files. (40.00%)
Exceptions:
  PdfExtractionError (Total: 2)
    - 1x Unable to extract content from PDF: '/home/azureuser/input_files/corrupt_docx.docx'
    - 1x Unable to extract content from PDF: '/home/azureuser/input_files/unsupported_filetype.txt'
2024-11-06 14:28:50.242 glasswall_conform.config.logging INFO     engine_mode                   Total elapsed time: 5.55 seconds

CDR सुरक्षा के बिना files का reconstruction

conform_only प्रोसेसिंग मोड CDR सुरक्षा प्रदान नहीं करता है, और इसके लिए एक input directory -i, एक output directory -o और एक --license path आवश्यक है। conform_only देखें।

glasswall_conform conform_only -i /home/azureuser/input_files -o /home/azureuser/output_files --license /home/azureuser/gwkey.lic

डिस्क से पढ़े या डिस्क पर लिखे बिना मेमोरी में फ़ाइलों को प्रोसेस करना

engine_memory और conform_only_memory प्रोसेसिंग मोड का उपयोग I/O के बिना मेमोरी में फ़ाइलों को प्रोसेस करने के लिए किया जा सकता है।

यदि प्रोसेसिंग सफल होती है, तो base64-encoded output file standard output के माध्यम से लौटाई जाती है। यदि प्रोसेसिंग के दौरान कोई त्रुटि होती है, तो एक error message और post processing summary standard error पर लिखी जाएगी।

timeout failure के लिए standard error का उदाहरण:

Error: Processing failed for file: 'hus11976.pdf'. Summary: {'conform_version': '0.11.2', 'operating_system': 'Windows', 'summary_verbosity': 'all', 'processing_rates': {'success': 0.0, 'failure': 100.0}, 'processing_counts': {'success': 0, 'failure': 1, 'total': 1}, 'processing_time': {'elapsed_seconds': 8.25, 'files_per_sec': 0.12, 'secs_per_file': 8.25}, 'processing_arguments': {'mode': 'engine_memory', 'library_directory': 'C:/azure/sdk.editor/2.1394.0/build-sdk-editor-windows-amd64-dev_license', 'cautious_mode': False, 'max_workers': 1, 'timeout_seconds': 5.0, 'memory_limit_gib': 11.96, 'function_name': 'protect_file', 'content_management_policy': None}, 'processing_success': [], 'processing_failure': [{'file_name': 'hus11976.pdf', 'timed_out': True, 'out_of_memory': False, 'max_memory_used_in_gib': 0.32227325439453125, 'elapsed_time': 5.0007593631744385, 'exception': 'TimeoutError()', 'success': False}]}

मूल उपयोग के उदाहरण:

मेमोरी में मौजूद PDF फ़ाइल की base64-encoded string को सीधे glasswall_conform में pipe करें

echo "U29tZUJhc2U2NERhdGE=" | glasswall_conform.exe engine_memory -l "C:/azure/sdk.editor/2.1394.0" --file-name "SomeBase64Data"

या subprocess के माध्यम से Python का उपयोग करके

import base64
import os
import subprocess

# File in memory, for this example simply loaded from a file path
file_path = r"C:\conform\input\Set-08-016599.pdf"
with open(file_path, "rb") as f:
    file_bytes = f.read()
# Convert to base64-encoded string
encoded_file_bytes = base64.b64encode(file_bytes).decode("utf-8")

file_name = os.path.basename(file_path)
command = " ".join(
    [
        "glasswall_conform",
        "engine_memory",
        '-l "C:/azure/sdk.editor/2.1394.0"',
        f'--file-name "{file_name}"',  # Optional, used for summary and logs
        f'--summary-path "C:/conform/summary_{file_name}.json"',  # Optional
        '--watermark "Processed for security: Visual elements may vary"',  # Optional
    ]
)
# Run Conform with the base64-encoded string as an input
result = subprocess.run(command, input=encoded_file_bytes, text=True, capture_output=True, shell=True)

if result.stderr:
    # Conform failed, handle error gracefully here
    print(result.stderr)
else:
    # Conform succeeded, convert the conformed file from base64 to bytes
    conformed_file_bytes = base64.b64decode(result.stdout)
    # Do something with the conformed file bytes, e.g. write to a file
    with open("conformed_file.pdf", "wb") as f:
        f.write(conformed_file_bytes)

इसी तरह, conform_only_memory mode का उपयोग ऊपर दिए गए उदाहरणों में engine_memory को बदलकर, -l argument को हटाकर, और --license निर्दिष्ट करके किया जा सकता है क्योंकि इस mode के लिए यह आवश्यक है।

तेज़ mode और cautious mode

Fast mode, Conform में डिफ़ॉल्ट processing mode है। यह PDF फ़ाइलों के लिए सबसे तेज़ processing speed और सर्वोत्तम visual appearance प्रदान करता है, लेकिन उन परिदृश्यों के लिए उपयुक्त नहीं हो सकता जिनमें PDF specifications के साथ बहुत सख्त compliance की आवश्यकता होती है।

यदि fast mode अक्षम है या किसी फ़ाइल को process नहीं कर सकता, तो Conform स्वचालित रूप से cautious mode पर वापस चला जाता है। यह mode embedded fonts को बदलकर compliance और risk reduction को प्राथमिकता देता है, जिससे custom या unknown fonts से जुड़ी समस्याओं को कम करने में मदद मिलती है। Cautious mode के परिणामस्वरूप visual fidelity कम हो सकती है, जैसे degraded या missing images, inconsistent font sizes, या missing text।

fast mode को अक्षम करने की सिफारिश केवल तभी की जाती है जब PDF standards के साथ बहुत कड़ा अनुपालन आवश्यक हो, भले ही इसके लिए visual fidelity की कीमत चुकानी पड़े।
cautious mode को अक्षम करने की सिफारिश केवल तभी की जाती है जब embedded fonts को सुरक्षित रखना आवश्यक हो, या जब visual appearance, Conform के लिए PDFs की अधिक व्यापक range को सफलतापूर्वक process कर पाने से अधिक महत्वपूर्ण हो।

Fast mode को वैकल्पिक --disable-fast-mode command line argument का उपयोग करके अक्षम किया जा सकता है। Cautious mode को वैकल्पिक --disable-cautious-mode command line argument का उपयोग करके अक्षम किया जा सकता है।

जब Conform fast mode का उपयोग करके किसी file को सफलतापूर्वक process करता है:

सबसे तेज़ प्रोसेसिंग गति।
सर्वोत्तम दृश्य रूप।
कस्टम embedded fonts को प्रतिस्थापित नहीं किया जाता है।
उन परिदृश्यों के लिए उपयुक्त नहीं हो सकता जिनमें PDF standards के साथ बहुत सख्त अनुपालन आवश्यक हो।

जब Conform cautious mode fallback का उपयोग करता है:

प्रोसेसिंग गति धीमी।
In a small number of cases, may result in reduced visual appearance, such as:
- छवियाँ और ग्राफ़िक्स खराब गुणवत्ता वाले हो सकते हैं या अनुपस्थित हो सकते हैं।
- टेक्स्ट के स्वरूप में अंतर (उदा. आकार, font style, या spacing)।
- जब अज्ञात embedded fonts उपयोग में हों, तो टेक्स्ट गायब हो सकता है।
PDFs को specifications के साथ अधिक सख्त अनुपालन के साथ प्रोसेस करता है।
कस्टम embedded fonts को ज्ञात-सुरक्षित fonts से प्रतिस्थापित करता है।

Glasswall Python Wrapper की कार्यक्षमता

engine processing mode में, Embedded Engine का उपयोग करके files को process करने के लिए डिफ़ॉल्ट रूप से Glasswall Python Wrapper का protect_file function उपयोग किया जाता है। इसे वैकल्पिक -f command line argument का उपयोग करके बदला जा सकता है।

A default sanitise content management policy is applied if a policy file is not specified using the optional -c command line argument.

आवश्यक -l command line argument को Embedded Engine वाली directory की ओर इंगित करना चाहिए।

निम्न arguments Glasswall Python Wrapper से संबंधित हैं:

  -l LIBRARY_DIRECTORY, --library-directory LIBRARY_DIRECTORY
                        Required. Path to directory containing the Embedded Engine.
  -f FUNCTION_NAME, --function-name FUNCTION_NAME
                        Optional. Glasswall Python Wrapper function name to call during multiprocessing, such as 'protect_file' or 'export_file'. Default: 'protect_file'.
  -c CONTENT_MANAGEMENT_POLICY, --content-management-policy CONTENT_MANAGEMENT_POLICY
                        Optional. Path to Embedded Engine content management policy file. If not provided, the default 'sanitise' policy is used.
  --log-level-console-wrapper {CRITICAL,ERROR,WARNING,INFO,DEBUG,NOTSET}
                        Optional. Set logging level for writing Glasswall Python Wrapper logs to console. Default INFO.

उदाहरण:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 -f protect_file -c /home/azureuser/glasswall/config.xml

Multiprocessing

सभी processing modes files को एक साथ कुशलतापूर्वक process करने के लिए Glasswall Python Wrapper के GlasswallProcessManager का उपयोग करते हैं।

निम्न arguments multiprocessing से संबंधित हैं:

  -w MAX_WORKERS, --max-workers MAX_WORKERS
                        Optional. Maximum workers for multiprocessing, 0=auto. Default: 0.
  -t TIMEOUT_SECONDS, --timeout-seconds TIMEOUT_SECONDS
                        Optional. Multiprocessing timeout per file in seconds. Default: 180.
  -m MEMORY_LIMIT_GIB, --memory-limit-gib MEMORY_LIMIT_GIB
                        Optional. Multiprocessing memory limit per file in GiB, 0=auto (4GiB min, worker distributed max). Default: 0.

उदाहरण:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 -t 300 -m 12

लॉगिंग

Conform और Glasswall Python Wrapper के लिए डिफ़ॉल्ट logging level INFO है। निम्न arguments logging से संबंधित हैं:

  --log-level-console {CRITICAL,ERROR,WARNING,INFO,DEBUG,NOTSET}
                        Optional. Set logging level for writing logs to console. Default INFO.
  --log-level-file {CRITICAL,ERROR,WARNING,INFO,DEBUG,NOTSET}
                        Optional. Set logging level for writing logs to file. If not provided, logs will not be written to file.
  --log-path LOG_PATH   Optional. Path to output log file. Default is a timestamp-named file located at: '%TEMP%/glasswall_conform/logs'.
  --log-level-console-wrapper {CRITICAL,ERROR,WARNING,INFO,DEBUG,NOTSET}
                        Optional. Set logging level for writing Glasswall Python Wrapper logs to console. Default INFO.

अधिकांश logging को दबाने के लिए:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --log-level-console CRITICAL --log-level-console-wrapper CRITICAL

कंटेंट हैंडलिंग दरों को अनुकूलित करें

यह अनुभाग केवल तब लागू होता है जब fast mode अक्षम हो।

डिफ़ॉल्ट रूप से, Conform जब भी संभव हो एक output file जनरेट करता है, भले ही मूल दस्तावेज़ की सामग्री का केवल एक हिस्सा ही सफलतापूर्वक हैंडल किया गया हो। यह व्यवहार हमेशा वांछनीय नहीं हो सकता, और प्रत्येक दस्तावेज़ के भीतर विभिन्न प्रकार की सामग्री के लिए इसे अनुकूलित किया जा सकता है।

Conform विकृत, भ्रष्ट, या असमर्थित text content को हैंडल करते समय "best guesses" का उपयोग करता है ताकि मूल दस्तावेज़ से conformed document में यथासंभव अधिक text स्थानांतरित किया जा सके। उदाहरण के लिए, यदि text का stroke colour विकृत है या असमर्थित colour format में है, तो output document में text बनाए रखा जाता है, और stroke colour डिफ़ॉल्ट रूप से black हो जाता है।

यह "best guess" तरीका ऐसे text का परिणाम दे सकता है जो मूल जैसा दिखाई दे, या कुछ मामलों में ऐसा text जो दिखाई न दे लेकिन फिर भी output document में मौजूद हो। क्योंकि हम यह गारंटी नहीं दे सकते कि हमारा best guess text को मूल दस्तावेज़ की तरह ही हैंडल करेगा, handling rate इसे ऐसी सामग्री के रूप में दर्शाता है जिसे पूरी तरह हैंडल नहीं किया गया है। परिणामस्वरूप, text के लिए कम handling rate हमेशा यह संकेत नहीं देता कि best guesses लागू होने पर दस्तावेज़ दृश्य रूप से अलग दिखाई देगा।

कंटेंट को हैंडल करते समय न्यूनतम success rates सेट करने के लिए तीन arguments उपलब्ध हैं:

  --text-min-success-rate TEXT_MIN_SUCCESS_RATE
                        Optional. The minimum success rate for processing text. Default: 0.0.
  --image-min-success-rate IMAGE_MIN_SUCCESS_RATE
                        Optional. The minimum success rate for processing images. Default: 0.0.
  --graphic-min-success-rate GRAPHIC_MIN_SUCCESS_RATE
                        Optional. The minimum success rate for processing graphics. Default: 0.0.

यदि न्यूनतम content handling rate मान पूरा नहीं होता है, तो दी गई file के लिए processing को विफल माना जाएगा और output file नहीं लिखी जाएगी।

वॉटरमार्किंग

वॉटरमार्किंग डिफ़ॉल्ट रूप से अक्षम होती है, लेकिन इसे --watermark argument का उपयोग करके सक्षम किया जा सकता है। 12 फ़ॉन्ट आकार में अर्ध-पारदर्शी गहरे धूसर रंग का text जोड़ा जाएगा। वॉटरमार्क सामान्यतः दस्तावेज़ के ऊपर-दाएँ भाग में रखा जाता है, हालांकि पृष्ठ पर लागू rotation के आधार पर इसकी orientation अलग हो सकती है। वॉटरमार्क के लिए अधिकतम text length वर्तमान में 256 characters है।

  --watermark WATERMARK
                        Optional. Adds a watermark to each page of the reconstructed document. Default '' (disabled).

उदाहरण:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --watermark "Glasswall Conform"

CID दमन

यह अनुभाग केवल तब लागू होता है जब fast mode अक्षम हो।

PDFs में, कुछ फ़ॉन्ट बड़े character sets को प्रबंधित करने के लिए CID (Character Identifier) नामक एक system का उपयोग करते हैं। नया PDF बनाते समय, यदि tool ऐसे characters पाता है जिन्हें process नहीं किया जा सकता, तो वह उन्हें डिफ़ॉल्ट प्रश्नवाचक चिह्न character (?) से बदल देता है। आप --suppress-cid argument का उपयोग करके अपने PDFs में unprocessable CIDs को कैसे दर्शाया जाए, इसे समायोजित कर सकते हैं:

  --suppress-cid SUPPRESS_CID
                        Optional. Replace CID metadata that may be printed to the visual layer due to font array omissions with the supplied string, with placeholder text.
                        Glasswall Conform restricts the processing of PDFs to only known secure fonts. This is a deliberate security feature to make the PDF conform safely. Default '■'.

उदाहरण:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --suppress-cid "?"

फ़ॉन्ट प्रतिस्थापन

यह अनुभाग केवल तब लागू होता है जब fast mode अक्षम हो।

Conform base 14 Type1 fonts और Cambria font के bold, italic, और bold italic variants का समर्थन करता है। Conform कुछ custom fonts का भी समर्थन करता है।

base 14 Type1 fonts हैं:

Courier, Courier-Bold, Courier-Oblique, Courier-BoldOblique
Helvetica, Helvetica-Bold, Helvetica-Oblique, Helvetica-BoldOblique
Times-Roman, Times-Bold, Times-Italic, Times-BoldItalic
Symbol
ZapfDingbats

जो embedded fonts समर्थित नहीं हैं, उन्हें Cambria font से बदला जा सकता है। यदि Cambria किसी embedded font के glyph का समर्थन नहीं करता, तो उस character को suppress कर दिया जाता है। इस बारे में अधिक जानकारी के लिए, CID suppression देखें।

डिफ़ॉल्ट रूप से, visual similarity के लिए कुछ सामान्यतः embedded sans serif fonts को Cambria के बजाय Helvetica से बदला जाता है। इसे, और अन्य font replacement features को, इन arguments का उपयोग करके संशोधित किया जा सकता है:

  --disable-base-14-fonts
                        Optional. Disable matching embedded fonts to base 14 fonts.
                        This will result in more fonts being replaced by the fallback font, Cambria. Default False.
  --disable-custom-fonts
                        Optional. Disable matching embedded fonts to custom fonts.
                        This will result in lower support for custom embedded fonts, and more fonts being replaced by the fallback font, Cambria. Default False.
  --disable-sans-serif-replacement
                        Optional. Disable replacing some sans serif fonts with Helvetica instead of the fallback font, Cambria.
                        This will result in some replaced sans serif fonts looking more visually different when compared to the original file. Default False.

उदाहरण:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --disable-custom-fonts

फ़ाइल समावेशन और बहिष्करण फ़िल्टरिंग

Conform, input directory में किन फ़ाइलों को प्रोसेस किया जाए, इस पर अतिरिक्त नियंत्रण include and exclude filters का उपयोग करके देता है। ये फ़िल्टर आपको command line से सीधे बुनियादी Unix shell-style wildcards का उपयोग करके यह निर्दिष्ट करने देते हैं कि किन फ़ाइलों को प्रोसेस करना है या अनदेखा करना है। यदि कोई फ़ाइल inclusion और exclusion दोनों नियमों से मेल खाती है, तो उसे excluded किया जाएगा।

डिफ़ॉल्ट रूप से, यदि --include-files और --exclude-files arguments छोड़े जाते हैं, तो Conform input directory में मौजूद सभी फ़ाइलों को प्रोसेस करेगा।

निम्न arguments फ़ाइल समावेशन और बहिष्करण से संबंधित हैं:

  --include-files INCLUDE_FILES
                        Optional. Can be either a path to a file containing file paths/patterns or a semicolon-separated list of patterns (e.g. '*.pdf;*/SET_03/*'). Only matching files will be processed.   
                        If None, all files are included. Default: None.
  --exclude-files EXCLUDE_FILES
                        Optional. Can be either a path to a file containing file paths/patterns or a semicolon-separated list of patterns. Any matching files will be excluded from processing. If None, no   
                        files are excluded. Default: None.

निम्न तालिका कुछ ऐसे patterns के उदाहरण दिखाती है जिनका उपयोग किया जा सकता है:

पैटर्न	अर्थ	उदाहरण	मेल खाता है	मेल नहीं खाता
`*`	सब कुछ से मेल खाता है	`*.pdf`	`file.pdf`, `report.pdf`	`file.docx`
`?`	किसी भी एकल वर्ण से मेल खाता है	`file_?.pdf`	`file_1.pdf`, `file_A.pdf`	`file_10.pdf`
`[seq]`	`seq` में किसी भी वर्ण से मेल खाता है	`file_[AB].pdf`	`file_A.pdf`, `file_B.pdf`	`file_C.pdf`
`[!seq]`	Matches any character not in `seq`	`file_[!AB].pdf`	`file_C.pdf`, `file_D.pdf`	`file_A.pdf`, `file_B.pdf`

केस संवेदनशीलता संबंधी विचार

फ़ाइल नाम Linux पर case-sensitive होते हैं, लेकिन Windows पर case-insensitive होते हैं। इससे यह प्रभावित होता है कि अलग-अलग ऑपरेटिंग सिस्टम पर फ़ाइल पथों या पैटर्न की व्याख्या कैसे की जाती है।

Linux पर, report.pdf और Report.pdf को अलग-अलग फ़ाइलों के रूप में माना जाता है।
Windows पर, दोनों को एक ही फ़ाइल माना जाता है।

सिफारिश: प्लेटफ़ॉर्म्स के बीच एकरूपता सुनिश्चित करने के लिए, फ़ाइल नामों और पैटर्न में एकसमान casing का उपयोग करें। यदि आप कई environments में काम कर रहे हैं, तो असंगतियों से बचने के लिए जहाँ उपयुक्त हो वहाँ wildcard patterns (*) का उपयोग करने पर विचार करें।

एकल फ़ाइल समावेशों को संभालना

यदि --include-files के साथ एक ही फ़ाइल निर्दिष्ट कर रहे हैं, तो ध्यान रखें कि Conform पहले यह जांचता है कि दिया गया मान disk पर मौजूद फ़ाइल है या नहीं, और यदि नहीं है तो उस मान को एक pattern के रूप में माना जाता है।

संभावित समस्या: यदि कोई उपयोगकर्ता यह निर्दिष्ट करता है:

--include-files "/home/azureuser/input_files/first.pdf"

Conform यह देखेगा कि /home/azureuser/input_files/first.pdf एक फ़ाइल के रूप में मौजूद है, और इसे ऐसे list file के रूप में पढ़ने का प्रयास करेगा जिसमें कई paths या patterns हों।

समाधान: यह स्पष्ट रूप से बताने के लिए कि यह एक single file के लिए pattern है, अंत में semicolon जोड़ें:

--include-files "/home/azureuser/input_files/first.pdf;"

यह सुनिश्चित करता है कि Conform path को list file के बजाय pattern के रूप में माने।

विशिष्ट PDF फ़ाइलें शामिल करें

फ़ाइल नाम में "report" वाले केवल PDFs को process करने के लिए:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --include-files "*report*.pdf"

परिणाम: केवल annual_report.pdf, summary_report_2023.pdf आदि जैसी फ़ाइलें process की जाती हैं।

विशिष्ट PDF फ़ाइलें बाहर रखें

नाम में "draft" वाली फ़ाइलों को छोड़कर सभी PDFs को process करने के लिए:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --exclude-files "*draft*.pdf"

परिणाम: proposal_draft.pdf और internal_draft_v2.pdf जैसी फ़ाइलों को छोड़कर सभी PDFs process की जाती हैं।

पूरी directory को बाहर रखें

/home/azureuser/input_files/archive/ के अंदर की सभी फ़ाइलों को बाहर रखने के लिए:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --exclude-files "*/archive/*"

परिणाम: /home/azureuser/input_files/archive/ के अंदर की हर चीज़ छोड़ दी जाती है।

Include और exclude साथ में

यदि कोई फ़ाइल inclusion और exclusion rule दोनों से मेल खाती है, तो उसे exclude किया जाएगा।

SET_03 की सभी फ़ाइलों को process करने के लिए, लेकिन "error_log" वाली फ़ाइलों को बाहर रखने के लिए:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --include-files "*/SET_03/*" --exclude-files "*error_log*"

परिणाम: केवल SET_03/ की फ़ाइलें process की जाती हैं, सिवाय उन फ़ाइलों के जिनके filename में "error_log" हो।

बड़ी सूचियों के लिए फ़ाइल का उपयोग करना

अधिक जटिल filtering के लिए, आप उन्हें सीधे निर्दिष्ट करने के बजाय कई patterns या absolute file paths वाली एक फ़ाइल दे सकते हैं।

inclusion list file का उपयोग करने का उदाहरण:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --include-files "include_list.txt"

include_list.txt का उदाहरण:

*/SET_03/*.pdf
*reports_2023_*.pdf
/home/azureuser/input_files/SET_02/splat.pdf

परिणाम: केवल SET_03/ की फ़ाइलें, reports_2023_ वाली फ़ाइलें, और विशेष फ़ाइल /home/azureuser/input_files/SET_02/splat.pdf process होती हैं।

आउटपुट फ़ाइल संरचना और वर्गीकरण

आउटपुट फ़ाइलों के लिए directory structure को engine और conform_only दोनों processing modes के लिए --output-structure command line argument का उपयोग करके अनुकूलित किया जा सकता है।

  --output-structure {categorised,mirrored}
                        Optional. Defines the directory structure of output files. 'categorised' organises output files into subdirectories based on processing status ('engine_success', 'conform_success', 'failure').
                        'mirrored' places successfully processed output files directly in the output directory, maintaining the original input directory structure, and failed files will not be copied. Default: categorised.   

यदि इसे छोड़ा जाता है, तो डिफ़ॉल्ट categorised संरचना का उपयोग किया जाता है। श्रेणी उप-डायरेक्टरी नामों को अनुकूलित करने के लिए अतिरिक्त विकल्प उपलब्ध हैं:

--engine-success-path: वैकल्पिक। उन files के लिए output subdirectory नाम जिन्हें Embedded Engine द्वारा Conform के reconstruction की आवश्यकता के बिना सफलतापूर्वक process किया गया। Default 01_engine_success
--conform-success-path: वैकल्पिक। उन files के लिए output subdirectory नाम जिन्हें प्रारंभ में Embedded Engine द्वारा process नहीं किया जा सका, लेकिन Conform द्वारा reconstruct किया गया और फिर Embedded Engine द्वारा सफलतापूर्वक process किया गया। Default 02_conform_engine_success
--failure-path: वैकल्पिक। उन files के लिए output subdirectory नाम जिन्हें Embedded Engine और Conform दोनों का उपयोग करके process नहीं किया जा सका। Default 03_failure

उदाहरण `categorised` आउटपुट संरचना

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0

उदाहरण input directory:

/home/azureuser/input_files
    conforming_docx.docx
    conforming_pdf.pdf
    corrupt_docx.docx
    nonconforming_pdf.pdf
    unsupported_filetype.txt

processing के बाद उदाहरण output directory:

/home/azureuser/output_files
├───01_engine_success
│       conforming_docx.docx
│       conforming_pdf.pdf
│
├───02_conform_engine_success
│       nonconforming_pdf.pdf
│
└───03_failure
        corrupt_docx.docx
        unsupported_filetype.txt

categorised आउटपुट संरचना का उपयोग करते समय, यदि यह वांछित हो कि सभी सफलतापूर्वक सुरक्षित की गई फ़ाइलें एक ही आउटपुट डायरेक्टरी में लिखी जाएँ, चाहे फ़ाइल को पुनर्निर्मित करने के लिए Conform का उपयोग किया गया हो या नहीं, तो आप फ़ाइलों को उसी success उप-डायरेक्टरी पथ में लिखने के लिए निर्दिष्ट कर सकते हैं। उदाहरण के लिए:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --engine-success-path success --conform-success-path success --failure-path failure

उदाहरण `mirrored` आउटपुट संरचना

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --output-structure mirrored

उदाहरण input directory:

/home/azureuser/input_files
    conforming_docx.docx
    conforming_pdf.pdf
    corrupt_docx.docx
    nonconforming_pdf.pdf
    unsupported_filetype.txt

processing के बाद उदाहरण output directory:

/home/azureuser/output_files
    conforming_docx.docx
    conforming_pdf.pdf
    nonconforming_pdf.pdf

पोस्ट प्रोसेसिंग सारांश

डिफ़ॉल्ट रूप से, Conform द्वारा फ़ाइलों की प्रोसेसिंग पूरी करने के बाद एक सारांश लिखा जाता है। यह सारांश प्रत्येक फ़ाइल के लिए return status, प्रोसेसिंग समय और मेमोरी उपयोग जैसी विस्तृत जानकारी प्रदान करता है। --summary-verbosity आर्ग्युमेंट नियंत्रित करता है कि सारांश में कौन-सी फ़ाइलें शामिल की जाएँ। यह सेटिंग logging level से स्वतंत्र है और विस्तृत log outputs को प्रभावित नहीं करती।

उपलब्ध विकल्प

all (डिफ़ॉल्ट) - इसमें सफलतापूर्वक प्रोसेस की गई और विफल दोनों प्रकार की फ़ाइलें शामिल होती हैं।
failure - इसमें केवल विफल फ़ाइलें शामिल होती हैं।
success - इसमें केवल सफलतापूर्वक प्रोसेस की गई फ़ाइलें शामिल होती हैं।
none - सारांश आउटपुट को पूरी तरह अक्षम करता है।

--summary-path आर्ग्युमेंट का उपयोग सारांश को केवल टर्मिनल में प्रदर्शित करने के बजाय डिस्क पर JSON फ़ाइल के रूप में लिखने के लिए किया जा सकता है।

सारांश आउटपुट में केवल विफल फ़ाइलों को शामिल करने का उदाहरण:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --summary-verbosity failure --summary-path /home/azureuser/conform_summary.json

सारांश आउटपुट को पूरी तरह अक्षम करने का उदाहरण:

glasswall_conform engine -i /home/azureuser/input_files -o /home/azureuser/output_files -l /home/azureuser/glasswall/Release-16.2.0 --summary-verbosity none --summary-path /home/azureuser/conform_summary.json

उदाहरण सारांश JSON आउटपुट (Windows):

{
    "conform_version": "0.10.1",
    "operating_system": "Windows",
    "summary_verbosity": "all",
    "processing_rates": {
        "success": 50.0,
        "failure": 50.0
    },
    "processing_counts": {
        "success": 2,
        "failure": 2,
        "total": 4
    },
    "processing_time": {
        "elapsed_seconds": 43.61,
        "files_per_sec": 0.09,
        "secs_per_file": 10.9
    },
    "processing_arguments": {
        "mode": "engine",
        "input_directory": "C:\\conform\\input",
        "output_directory": "C:\\conform\\output",
        "library_directory": "C:\\azure\\sdk.editor\\2.1394.0",
        "cautious_mode": false,
        "max_workers": 3,
        "timeout_seconds": 180,
        "memory_limit_gib": 4.35,
        "function_name": "protect_file",
        "content_management_policy": null,
        "include_files": null,
        "exclude_files": null,
        "output_structure": "categorised"
    },
    "processing_success": [
        {
            "input_file": "C:\\conform\\input\\pal1.bmp",
            "output_file": "C:\\conform\\output\\01_engine_success\\pal1.bmp",
            "engine_status": "OK(0)",
            "max_memory_used_in_gib": 0.11124420166015625,
            "elapsed_time": 0.9149298667907715,
            "success": true
        },
        {
            "input_file": "C:\\conform\\input\\Set-08-016599.pdf",
            "output_file": "C:\\conform\\output\\02_conform_engine_success\\Set-08-016599.pdf",
            "engine_status": "GeneralFail(-1)",
            "engine_GW2FileErrorMsg": "[FAILURE_LOG_SEM_FONTS_0021897368] Key /FirstChar must be present in a Type 1 Font dictionary other than for standard 14. fonts.",
            "engine_conform_fast_status": "GeneralFail(-1)",
            "engine_conform_fast_GW2FileErrorMsg": "[FAILURE_LOG_SEM_FONTS_0021897368] Key /FirstChar must be present in a Type 1 Font dictionary other than for standard 14. fonts.",
            "engine_conform_cautious_status": "OK(0)",
            "max_memory_used_in_gib": 0.22198104858398438,
            "elapsed_time": 1.8940067291259766,
            "success": true
        }
    ],
    "processing_failure": [
        {
            "input_file": "C:\\conform\\input\\pal1_corrupt.bmp",
            "engine_status": "FileTypeUnknown(-7)",
            "engine_GW2FileErrorMsg": "Unable to determine file type",
            "engine_conform_fast_status": "PdfFastProcessError()",
            "engine_conform_cautious_status": "PdfExtractionError(Unable to extract content from PDF: 'C:\\conform\\input\\pal1_corrupt.bmp')",
            "exit_code": 0,
            "timed_out": false,
            "out_of_memory": false,
            "max_memory_used_in_gib": 0.13513565063476562,
            "elapsed_time": 0.8690056800842285,
            "success": false
        },
        {
            "input_file": "C:\\conform\\input\\Straw120556398.pdf",
            "timed_out": false,
            "out_of_memory": true,
            "max_memory_used_in_gib": 4.3571624755859375,
            "elapsed_time": 41.976775884628296,
            "exception": "MemoryError()",
            "success": false
        }
    ]
}

स्थापना​

Windows​

Linux​

RPM (उदा. Rocky 9, Rocky 8)​

DEB (उदा. Ubuntu 24.04, Ubuntu 22.04)​

सेटअप​

Linux​

Ubuntu​

Windows​

लाइसेंसिंग​

Processing modes​

engine​

conform_only​

engine_memory​

conform_only_memory​

परीक्षण​

उदाहरण​

एंड-टू-एंड सुरक्षा​

CDR सुरक्षा के बिना files का reconstruction​

डिस्क से पढ़े या डिस्क पर लिखे बिना मेमोरी में फ़ाइलों को प्रोसेस करना​

तेज़ mode और cautious mode​

Glasswall Python Wrapper की कार्यक्षमता​

Multiprocessing​

लॉगिंग​

कंटेंट हैंडलिंग दरों को अनुकूलित करें​

वॉटरमार्किंग​

CID दमन​

फ़ॉन्ट प्रतिस्थापन​

फ़ाइल समावेशन और बहिष्करण फ़िल्टरिंग​

केस संवेदनशीलता संबंधी विचार​

एकल फ़ाइल समावेशों को संभालना​

विशिष्ट PDF फ़ाइलें शामिल करें​

विशिष्ट PDF फ़ाइलें बाहर रखें​

पूरी directory को बाहर रखें​

Include और exclude साथ में​

बड़ी सूचियों के लिए फ़ाइल का उपयोग करना​

आउटपुट फ़ाइल संरचना और वर्गीकरण​

उदाहरण categorised आउटपुट संरचना​

उदाहरण mirrored आउटपुट संरचना​

पोस्ट प्रोसेसिंग सारांश​

स्थापना

Windows

Linux

RPM (उदा. Rocky 9, Rocky 8)

DEB (उदा. Ubuntu 24.04, Ubuntu 22.04)

सेटअप

Linux

Ubuntu

Windows

लाइसेंसिंग

Processing modes

engine

conform_only

engine_memory

conform_only_memory

परीक्षण

उदाहरण

एंड-टू-एंड सुरक्षा

CDR सुरक्षा के बिना files का reconstruction

डिस्क से पढ़े या डिस्क पर लिखे बिना मेमोरी में फ़ाइलों को प्रोसेस करना

तेज़ mode और cautious mode

Glasswall Python Wrapper की कार्यक्षमता

Multiprocessing

लॉगिंग

कंटेंट हैंडलिंग दरों को अनुकूलित करें

वॉटरमार्किंग

CID दमन

फ़ॉन्ट प्रतिस्थापन

फ़ाइल समावेशन और बहिष्करण फ़िल्टरिंग

केस संवेदनशीलता संबंधी विचार

एकल फ़ाइल समावेशों को संभालना

विशिष्ट PDF फ़ाइलें शामिल करें

विशिष्ट PDF फ़ाइलें बाहर रखें

पूरी directory को बाहर रखें

Include और exclude साथ में

बड़ी सूचियों के लिए फ़ाइल का उपयोग करना

आउटपुट फ़ाइल संरचना और वर्गीकरण

उदाहरण `categorised` आउटपुट संरचना

उदाहरण `mirrored` आउटपुट संरचना

पोस्ट प्रोसेसिंग सारांश