[Feature Request] Convert DOCX to native searchable/selectable PDF instead of rasterized images

[MahmoudhassanGX]

Current Behavior

When converting .docx documents to .pdf, the resulting PDF appears to render pages as rasterized static images embedded inside the PDF. This makes the text non-selectable, non-searchable, and prevents copying content (unlike the native "Save as PDF" feature in Microsoft Word or LibreOffice).

Proposed Improvement

Please support converting DOCX files into native vector-based, searchable PDFs:

• Preserve selectable and copyable text.
• Maintain document formatting and text sharpness without rasterizing full pages into images.
• (Optional) If headless LibreOffice, docx2pdf, or an engine like Weasyprint / Pandoc / native Word COM is used under the hood, ensure the export preserves the PDF text layer.

Benefit

This drastically reduces PDF file size, allows text selection/searching/copying, and ensures professional export quality.

[MahmoudhassanGX]

Note on "Out-of-the-Box" Experience & Defaults

It’s very possible that some of these tools or capabilities already exist under the hood or can be enabled via deep configuration. However, from a practical UX and user-retention perspective:

1. Users Rely on Defaults: The vast majority of everyday users stick to the default settings and rarely dive into advanced or hidden menus.
2. First Impressions Drive Retention: If an essential feature (like clean PDF text export or intuitive multi-image merging) doesn't work well out of the box, users often assume the software simply lacks the capability.
3. Preventing Churn: Instead of digging through complex settings, users typically uninstall the app and search for ready-made alternatives.

Takeaway:
Surfacing these capabilities through smarter default settings (rather than burying them behind manual configuration) will dramatically improve user retention and make the application feel polished and reliable from the very first run.

[KnifeLemon]

Thanks! Filee's Word → PDF output has real text: the fonts are embedded (subset) with a ToUnicode map, so the text can be searched, selected and copied. I checked a DOCX → PDF with the current version just now. If a PDF of yours behaves like a picture, could you tell us your Filee version, the preset you used, and attach the DOCX (or a page of it)?

[MahmoudhassanGX]

Verification Note: Based on current document rasterization pipelines and Tesseract multi-script capabilities as of October 28, 2026[cite: 1].

Thanks for the clarification!

The root cause of the friction is the default pipeline behavior:
When standard users drag and drop documents, the default workflow currently renders pages as static raster images inside the PDF without an active OCR layer[cite: 1]. The text appears as a flat image, leading to larger file sizes, lower visual sharpness, and unselectable content[cite: 1].

To solve this across the entire application once and for all:

1. Enable OCR as an Active Global Default

• Instead of keeping OCR hidden or optional inside individual presets[cite: 1, 3], it should act as an automatic baseline: any document or image converted to PDF should automatically receive a searchable text layer[cite: 3].
• A simple master toggle in Advanced settings ([On/Off]) allows users to disable it if they need purely lightweight, instantaneous conversions[cite: 3].

2. Universal Auto-Language & Script Detection (No Manual Guessing)

Users often handle documents containing unfamiliar scripts (e.g., Thai, Tagalog, Vietnamese, or mixed Arabic/French) where manually selecting language packs is impractical.

• Script-Based OCR Loading: Instead of restricting OCR to a single rigid dictionary, Tesseract can utilize script-level models (e.g., script/Arabic + script/Latin) combined with OSD (Orientation and Script Detection).
• This allows the engine to autonomously detect the character set and transcribe multi-lingual pages natively.

3. Bidirectional (BiDi) Logic to Prevent Reversed Text

• When extracting mixed RTL/LTR texts (like Arabic mixed with English or French), running the extracted text through standard Unicode BiDi reordering before embedding the invisible PDF layer prevents characters and words from appearing inverted or scrambled when selected/copied.

Making multi-language OCR an automatic out-of-the-box standard ensures Filee behaves like modern office suites—delivering sharp, fully selectable, and searchable PDFs every single time[cite: 1].

Just to share my perspective as a user (MahmoudhassanGX):

When I highlight these points, it comes from a very simple philosophy:
Whether a feature is completely missing or already built-in under the hood, the real secret to a great app is how it feels right out of the box[cite: 1].

The everyday user installs the app, drags their files, and wants to enjoy a smooth, instant result without touching a single setting[cite: 3]. If they have to dig through menus, configure presets, or figure out why text isn't selectable, the magic is lost[cite: 1, 3].

Making high-quality, searchable output the default standard is the radical, simple fix that turns a first-time downloader into a loyal, long-term user[cite: 1, 3]. That’s really all I'm aiming for—pure usability from second one!

[MahmoudhassanGX]

Just to share my perspective as a user (MahmoudhassanGX):

When I highlight these points, it comes from a very simple philosophy:
Whether a feature is completely missing or already built-in under the hood, the real secret to a great app is how it feels right out of the box[cite: 1].

Today's everyday user is already accustomed to the standard "Save as PDF" output in modern Microsoft Word or LibreOffice[cite: 1]:

• Clean, crisp, native vector text that preserves exact formatting[cite: 1].
• Immediate, effortless text selection, copying, and global searching without manual tweaking[cite: 1].

Users will simply not compromise on this baseline[cite: 1]. If an app exports static, rasterized page captures or requires deep preset tinkering just to get readable text, the initial magic is broken[cite: 1, 3].

The everyday user installs the app, drags their files, and wants to enjoy an output that rivals the latest office suites immediately[cite: 1, 3]. Making this modern, searchable standard the active default is the radical, simple fix that turns first-time downloaders into loyal, long-term users[cite: 1, 3]. That is truly what will keep Filee ahead of the pack[cite: 1, 3]!

[MahmoudhassanGX]

🛠️ Proposed Implementation Architecture (Native Text & Zero-Config Pipeline)

To eliminate rasterization fallbacks and match the output quality of modern suites (Word/LibreOffice), the conversion pipeline can enforce native vector export and automatic OCR fallback through this workflow:

1. Enforcing Native Headless Export (Primary Pipeline)

When converting .docx via headless office engines (such as LibreOffice / soffice or direct Word COM), ensure standard PDF export filters are passed explicitly with font embedding and vector preservation flags, rather than relying on image printers:

C#
var startInfo = new ProcessStartInfo
{
    FileName = officeBinaryPath,
    Arguments = $"--headless --convert-to pdf:writer_pdf_Export:\"{{\\\"SelectPdfVersion\\\":{{\\\"type\\\":\\\"long\\\",\\\"value\\\":\\\"1\\\"}},\\\"EmbedStandardFonts\\\":{{\\\"type\\\":\\\"boolean\\\",\\\"value\\\":\\\"true\\\"}}}}\" \"{inputFilePath}\" --outdir \"{outputDirectory}\"",
    CreateNoWindow = true,
    UseShellExecute = false
};

2. Automatic Intelligent OCR Fallback (Zero-Config Default)
   If a source document contains scanned pages or rasterized components, the global pipeline can verify if a native text layer exists; if absent, it transparently applies OCR before finishing:

`public async Task<string> ProcessDocumentToPdfAsync(string inputPath, ConversionOptions options)
{
    // Step 1: Attempt native direct vector export
    string pdfPath = await ExecuteNativeOfficeExportAsync(inputPath);

    // Step 2: Check if PDF has extractable text (e.g., using PdfPig or Poppler text check)
    bool hasTextLayer = PdfUtility.HasSelectableText(pdfPath);

    // Step 3: If text is missing (scanned document), trigger multi-script OCR automatically
    if (!hasTextLayer && options.EnableAutoOcrDefault)
    {
        pdfPath = await OcrService.InjectInvisibleTextLayerAsync(
            pdfPath, 
            languages: "ara+eng+fra+script/Latin", 
            applyBidiOrdering: true
        );
    }

    return pdfPath;
}`

3. Automatic BiDi Text Reordering for Arabic / Complex Scripts
   To prevent reversed or disconnected characters when users copy extracted text:

`// Normalize BiDi text before writing the hidden text layer
public string NormalizeExtractedText(string rawOcrText)
{
    // Apply Unicode Bidirectional Algorithm (UBA) logical reordering
    var bidi = new Bidi();
    return bidi.GetLogicalToVisualRun(rawOcrText);
}`

This structural separation guarantees that users get pristine vector documents by default[cite: 1], while edge-case image scans are rescued transparently by OCR without touching a single setting

[KnifeLemon]

Thanks. To keep this concrete:

• With Filee's default settings, a DOCX → PDF has real text: the fonts are embedded with a ToUnicode map, so the text can be searched, selected and copied. Pages aren't turned into pictures, so there's no raster default to change, and Word documents need no OCR.
• OCR is for scans and pictures, and it's in the presets that need it.

If you have a DOCX whose PDF comes out as a picture, please open an issue with that DOCX and your Filee version: that would be a bug, and we'd look at it. Closing this idea, since what it asks for is already the default.