Eml-to-pdf bug fixes: removal of incompatible fonts, removal of emoji in favor of @, jakarta-mail dependency handling improvements

[balazs-szucs]

Description of Changes

This pull request introduces enhancements and code cleanup to the EmlToPdf utility class, focusing on improving email-to-PDF conversion, handling embedded images, and simplifying the codebase. Key changes include better handling of inline images, enhanced Jakarta Mail dependency checks, and refactoring for improved readability and maintainability.

Enhancements to Email-to-PDF Conversion:

• Added support for processing inline images (cid: references) by converting them into data URIs for proper inline display.
• Improved attachment handling to always include embedded images regardless of size, ensuring inline display functionality.
• Enhanced email HTML generation to process inline images and include them in the email body.

Attachment Handling Enhancements:

• Replaced the attachment icon placeholder (icon or 📎 emoji) with a new marker (@) for consistency across the application (non-fat images did not support the emoji, however @ is supported accross the board.)
• Updated the annotation logic to use AttachmentMarkerPositionFinder instead of EmojiPositionFinder, aligning with the new attachment marker system.

Jakarta Mail Dependency Handling:

• Added detailed checks for core Jakarta Mail classes to determine availability in different environments (e.g., Docker).
• Introduced validation for Jakarta Mail multipart and part types to prevent processing invalid objects.
• Explicitly parse in the classes:

• jakarta.mail.internet.MimeMessage – Core email message parsing
• jakarta.mail.Session – Email session management
• jakarta.mail.internet.MimeUtility – MIME encoding/decoding utilities
• jakarta.mail.internet.MimePart – Individual MIME parts (attachments, body parts)
• jakarta.mail.internet.MimeMultipart – Multi-part MIME messages
• jakarta.mail.Multipart – Base multipart interface
• jakarta.mail.Part – Base part interface

Code Cleanup and Refactoring:

• Simplified utility classes (StyleConstants, MimeConstants, FileSizeConstants) by removing unnecessary constructors and unused constants.
• Updated log messages for clarity, such as distinguishing between general content processing errors and multipart-specific issues.

---

Checklist

General

• I have read the Contribution Guidelines
• I have read the Stirling-PDF Developer Guide (if applicable)
• I have read the How to add new languages to Stirling-PDF (if applicable)
• I have performed a self-review of my own code
• My changes generate no new warnings

Documentation

• I have updated relevant docs on Stirling-PDF's doc repo (if functionality has heavily changed)
• I have read the section Add New Translation Tags (for new translation tags only)

UI Changes (if applicable)

• Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR)

Testing (if applicable)

• I have tested my changes locally. Refer to the Testing Guide for more details.

[Copilot]

Pull Request Overview

This pull request refactors the EmlToPdf utility to address inline image processing, replace unsupported emoji representations with an "@" marker, and improve Jakarta Mail dependency handling for enhanced email-to-PDF conversion.

• Updates style and MIME constants to simplify font and attachment marker management
• Enhances inline image processing, logging, and reflection-based constructor usage
• Refactors attachment and multipart processing with additional Jakarta Mail type checks

Comments suppressed due to low confidence (2)

common/src/main/java/stirling/software/common/util/EmlToPdf.java:1693

• The original EmojiPositionFinder constructor declared throwing IOException due to PDFTextStripper's constructor. Verify that removing the throws clause in AttachmentMarkerPositionFinder does not lead to unhandled IO issues or compilation errors with PDFBox.

        public AttachmentMarkerPositionFinder() {

common/src/main/java/stirling/software/common/util/EmlToPdf.java:183

• Changing validateEmlInput to no longer throw IOException (and instead relying on IllegalArgumentException) could affect callers expecting IO-related exceptions. Confirm that downstream error handling is adjusted accordingly.

    private static void validateEmlInput(byte[] emlBytes) {

[Frooodle]

what is it missing that causes the Jakarta Mail libraries to be missing? what system dep?

[balazs-szucs]

I do think that the font was my own fault, but Jakarta Mail problem was partly missing version.properties. I added better fallback to this, and kind more explicit checks. I tried to be more explicit in how the especially the content part handled e.g in processMultipartAdvanced/Image handling just in case and that seem to solve the other part of it. In my testing, when I added logging there it seemed like it wasn't even called or reached by the code when in docker. Not 100% sure why.

Anyhow, I spent considerable time testing this with all sorts of edge cases, and I am confident about this.

[balazs-szucs]

Do you think it would be wise to add junit Test to this? I think that would levitate some concerns , and making emails for testing that would fail without proper dependencies wouldn't be that hard. But I didn't check this beforehand so this is just a guess.

[Frooodle]

JUnits are welcome to add but not a requirement for the repo, although we should start requiring that tbf...

[balazs-szucs]

Makes sense. I wouldn't mix Junit test with this per se, but I'll work on that then. Sorry for inconvenience on this.

[Frooodle]

Ill merge this code as is, junits can be separate