is there any way we can edit the existing data of the pdf using lexical ??

[Krush-aiden]

Feasibility Advice: Building a text/table PDF editor with Lexical (Coordinate-mapping vs. Reflowable layout)

Hello Lexical Team and Community,

I am evaluating rich-text frameworks to build a web-based PDF Editor. The target PDF documents are structurally simple, containing only standard text paragraphs and data tables—no complex designs or vector graphics.

I want to see if Lexical is the right tool for this architecture, specifically regarding how it handles document layouts and data conversion.

The Proposed Workflow:

1. Backend Extraction: A backend service parses an uploaded PDF, extracting text blocks, table data, and their bounding box coordinates (x, y, width, height).
2. Editor Layer: We want to render this data inside Lexical to make it completely editable by the user.
3. Export Layer: Once edited, the state needs to be saved back out—either as a PDF directly, or converted to a Word document (.docx) first and then compiled back into a final PDF.

The Main Architectural Dilemma:

PDFs are inherently static and coordinate-based, whereas Lexical is designed as a flowable, tree-based rich text engine (similar to Word or Google Docs). I am trying to determine the best approach within Lexical's ecosystem:

• Approach A (Absolute Positioning): Can Lexical accommodate a canvas-like layout where custom Nodes are absolutely positioned using the coordinates extracted from the backend?
• Approach B (Semantic Translation): Is it wiser to discard the raw coordinates entirely on the backend, translate the PDF into semantic HTML/JSON elements (like paragraphs and native TableNodes), let Lexical handle it as a standard reflowable document, and re-layout the PDF during the final export phase?

Questions for the Maintainers & Community:

1. Coordinate-Based Editing: Has anyone successfully used Lexical for absolute-positioned text block editing, or does forcing a non-default layout engine go heavily against Lexical's core design principles?
2. Table Node Robustness: How reliable is the native Table plugin when handling heavy text mutation and cell data manipulation if our ultimate goal is consistent HTML/JSON serialization for PDF conversion?
3. Alternative Recommendations: If Lexical isn't the ideal fit for handling absolute canvas layouts but is excellent for the reflowable Word-to-PDF approach, are there specific pitfalls we should look out for regarding state hydration from a parsed document?

Any insights, architectural warnings, or examples of similar implementations would be incredibly helpful! Thank you.

[etrepum]

Anything is possible with enough code.

lexical doesn’t have a layout engine, it’s all just html and css, and you have a lot of control over that especially with the new DOMRenderExtension. If you can figure out how to model the layout in html you just need to apply the same rules to how the nodes render.

tables work fine.

lexical doesn’t ship with any code to deal with pdf or docx in either direction, but that’s just a matter of writing the code to do the import and export. Should be fairly straightforward.