Thank you for your work on additional schema support.

I'm interested in printing maps with pdfme, where maps would be embedded in the PDF together with other content.

I have created a schema for the signature.

Playground: playground.pdfme.com
Code: https://github.com/pdfme/pdfme-playground/blob/main/src/plugins/signature.ts

In pdfme v2, we forked our version so that we could allow editors to mix dynamic and static content within a single text schema:

We will look to re-implement this within v3 as a custom schema. However, we will consider ways to improve both UX and functionality.

One idea I had was to allow editors to introduce multiple variables into a single text schema simply by surrounding them with { } when typing, e.g.:

Hi {name}, thanks for buying {product}, we hope you enjoy it.

• This allows the style, sizing and spacing of the text with multiple dynamic variables
• Also just static text schema with no variables at all.

Unfortunately, I think this is probably not possible right now as the relationship of input vars to schema is probably 1-to-1.
I will investigate this further in the coming weeks and see what we can do.

MEMO

• readOnlyText
• line
• rectangle
• circle

Not sure if this makes sense, but a set of "common" types could ensure that input data is formatted correctly.

With "common types" I mean for example:

• Numbers (which can be even distinguish between integer or float for example)
• Boolean ... maybe this could be rendered as checkboxes for example
• Date/time (timestamp), duration

Or others like:

• Hyperlink
• Currency
• List (simple or key/value) or enums ... could be shown as dropdowns

Do you already have some sort of documentation how to correctly add plugins/schema?

Hi ... I would need a checkbox schema :) ... thank you

Hi... I had a need in the image schema, I made a change to meet it, an opacity option in the images, a practical example, like a watermark. It would be interesting to be in the Git Hub source code, so I don't need to control the source separately.

Change follows:

Result:

I've started some dev on making a form text field plugin, it's like a cut down text plugin, but means the output is editable in the final pdf. Is the intent to make plugins stand alone, or move them into the main pdfme/plugins module?
I noticed that the barcode plugin is in the playground code, not plugins. There is a couple of things that would be handy if they are exported from the plugins code base, so I can reuse existing functionality and types if you new plugins to be external.

Would be really nice to have support for checkboxes and radioboxes! Going further, it would be even cooler to have support for conditional rendering of additional static data/form inputs based on the state of such checkboxes/radioboxes.

Hey @hand-dot do you have any plugin coded which is like a row container having no. of columns like flex row and children will be reltive to that parent container

hi @hand-dot , you are doing some amazing work there. I am a freelancer and using pdfme in one of my ongoing projects. Your library is the nicest abstraction that meet our needs. We understand that pdfme is under ongoing development. here are some features we would love to have. Fillable checkboxes, options, calendar date picker. We are thinking of creating our own plugins for the time being. If anyone from the community have such solutions already built, please do share. That would be really helpful.

Hi @hand-dot, Here are 3 requirements I'm not sure it's already accomplished.

1. Generate PDF with dynamic pictures
   For example
   There is a checklist, and each check item may have none or multiple pictures.
   And the requirement is to export all the check items and pictures in one PDF.
2. Report header/footer which the whole PDF has one header at the beginning and one footer at the end. And Page header/footer which will shown for each page.
3. According to the data hide/show some fields, don't need to create different templates for various scenarios.

I was looking for a way to create a field that would be editable after the PDF is exported similar to what @jedimonkey mentioned here. I wasn't able to find support to it on the lib or any plugin. Posting it here in case someone knows a plugin or a workaround to achieve it. Thanks

Variable font/Bold, italics, bold-italic support

Hii @hand-dot,
I am trying to achieve the functionality of "bold", "italic" and "bold-italic" at a field level.
In a previous attempt of mine in version 2, I had made a hacky way where I would change fonts to achieve this.
Along with that I had multiple font support i.e Arial, Roboto, Helvetica, etc. Along with their bold, italic, bold-italic versions.
Reason being pdf-lib not natively supporting any of this functionality.

My end goal is to add a schema for rich-text field.
So is there any natively supported functions to handle variable fonts in pdfme/pdf-lib, if not are you planning to add them any time soon.
I am assuming that variable fonts support is quite difficult and will not be added anytime soon
If not then a basic functionality of adding in bold, italic and bold-italic variants of a font.

Current implementation in v5.2.10

const fontObjList = [
  {
    fallback: true,
    label: 'NotoSerifJP-Regular',
    url: '/fonts/NotoSerifJP-Regular.otf',
  },
  {
    fallback: false,
    label: 'NotoSansJP-Regular',
    url: '/fonts/NotoSansJP-Regular.otf',
  },
  {
    fallback: false,
    label: DEFAULT_FONT_NAME,
    data: getDefaultFont()[DEFAULT_FONT_NAME].data,
  },
];

Desired implementation [would you consider this implementation reasonable]

// variants would be optional
// if a variant is not found fallback to regular font
const fontObjList = [
  {
    fallback: true,
    label: 'NotoSerifJP',
    url: '/fonts/NotoSerifJP-Regular.otf'
    variants: {
        bold: '/fonts/NotoSerifJP-Bold.otf'
        italic: '/fonts/NotoSerifJP-Italic.otf'
        boldItalic: '/fonts/NotoSerifJP-BoldItalic.otf'
    }
  },
  {
    fallback: false,
    label: 'NotoSansJP',
    url: '/fonts/NotoSansJP-Regular.otf',
    // no variants avaiable for this font
  },
  {
    fallback: false,
    label: DEFAULT_FONT_NAME,
    data: getDefaultFont()[DEFAULT_FONT_NAME].data,
  },
];

TextSchema modifications

{
    // ... other properties,
    bold?: boolean, 
    // or
    fontWeight?: 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900,
    italic?: boolean
}

Hey @hand-dot,
Implementing your awesome library, i needed a schema to add hyperlinks on text.
Its not using any external library, and uses the same prop panel and parameters as text.

guide

create schemas directory where you need it and copy anything from node_modules\@pdfme\schemas\dist\types\src
create schemas/link/link.ts

copy the following code in link.ts

import { PDFRenderProps, Plugin } from "@pdfme/common";
import { PDFString } from "@pdfme/pdf-lib";
import { Link } from "lucide";
import text from "../text";
import { pdfRender as parentPdfRender } from "../text/pdfRender";
import { TextSchema } from "../text/types";
import { convertForPdfLayoutProps, createSvgStr } from "../utils";

// inputs : [["text","url"]]

export interface LinkSchema extends TextSchema {
  url: string;
}

export const link: Plugin<LinkSchema> = {
  ui: text.ui,
  pdf: async (arg: PDFRenderProps<LinkSchema>) => {
    const { value, pdfDoc, schema, page, ...rest } = arg;
    const pageHeight = page.getHeight();
    const {
      width,
      height,
      position: { x, y },
    } = convertForPdfLayoutProps({ schema, pageHeight, applyRotateTranslate: false });
    const values: string[][] = JSON.parse(value);
    page.node.addAnnot(
      pdfDoc.context.register(
        pdfDoc.context.obj({
          Type: "Annot",
          Subtype: "Link",
          Rect: [x, y, x + width, y + height],
          // Border: [0, 0, 0],
          // border color
          // C: [0, 0, 1],
          // URI action
          A: {
            Type: "Action",
            S: "URI",
            URI: PDFString.of(values[0][1]),
            // still searching for that one
            // target: "_blank", 
          },
        }),
      ),
    );
    const renderArgs = {
      value: values[0][0],
      pdfDoc: pdfDoc,
      schema,
      page: page,
      ...rest,
    };

    await parentPdfRender(renderArgs);
  },
  propPanel: {
    schema: text.propPanel.schema,
    defaultSchema: {
      ...text.propPanel.defaultSchema,
      rotate: undefined,
      type: "link",
      url: "",
    },
  },
  icon: createSvgStr(Link),
};

export default link;

edit schemas/index.ts to make it export the new plugin

import barcodes from "./barcodes/index";
import checkbox from "./checkbox/index";
import date from "./date/date";
import dateTime from "./date/dateTime";
import time from "./date/time";
import image from "./graphics/image";
import svg from "./graphics/svg";
// link added
import link from "./link/link";
import multiVariableText from "./multiVariableText/index";
import radioGroup from "./radioGroup/index";
import select from "./select/index";
import line from "./shapes/line";
import { ellipse, rectangle } from "./shapes/rectAndEllipse";
import table from "./tables/index";
import text from "./text/index";

const builtInPlugins = { Text: text };

export {
  barcodes,
  builtInPlugins,
  checkbox,
  date,
  dateTime,
  ellipse,
  image,
  line,
  multiVariableText,
  radioGroup,
  rectangle,
  select,
  svg,
  table,
  text,
  time,
  // link added
  link,
};

hover on a generated link...

Feature Request: Enhanced Text Styling Options for PDFme

Currently, PDFme's text schema lacks built-in support for rich text formatting, which limits design flexibility when generating PDF templates. I propose adding comprehensive text styling options that would include:

1. Text Formatting Capabilities

• Bold text styling
• Italic text styling
• Underline text styling
• Combination of formatting (e.g., bold italic)

2. Potential Implementation Approaches

// Example proposed schema structure
{
  type: 'text',
  text: 'Sample Text',
  fontStyle: {
    bold: true,
    italic: false,
    underline: false
  }
}

3. Key Benefits

• More dynamic text rendering in PDF templates
• Increased design flexibility
• Simplified text styling workflow
• Consistent rendering across UI and PDF generation

Technical Considerations

• Extend existing text schema plugin
• Modify UI and PDF rendering methods
• Ensure compatibility with current PDFme architecture
• Provide backward compatibility with existing templates

Example Implementation Prototype

const richTextPlugin = {
  ui: (props) => {
    const { schema, value } = props;
    const span = document.createElement('span');
    span.textContent = value;
    
    // Apply styling based on fontStyle configuration
    span.style.fontWeight = schema.fontStyle?.bold ? 'bold' : 'normal';
    span.style.fontStyle = schema.fontStyle?.italic ? 'italic' : 'normal';
    span.style.textDecoration = schema.fontStyle?.underline ? 'underline' : 'none';
  },
  pdf: (props) => {
    // Custom PDF rendering logic
  }
};

Questions for Community

• Would this approach meet your text styling requirements?
• What additional formatting options would be valuable?
• Are there specific use cases I might have overlooked?

I'm happy to collaborate on refining this proposal and potentially contribute a pull request if there's community interest.

Proposed countermeasure for overflow generated by TextSchema

Hi @hand-dot

Today I would like to propose a feature in pdfme text display that does not display strings that are out of bounds.

Summary

Problem

Text in TextSchema is currently allowed to extend beyond the container, but this does not guarantee that the output will follow a predefined layout.

We feel that the current situation is a challenge for documents where layout is important, such as invoices and estimates, where text processing and validation cannot follow the pdfme rendering logic.

Proposal

I would like to add a new boolean option to TextSchema. This option would explicitly control text overflow and ensure that the rendered output always respects the defined bounds.

advantage

• For developers
  • Provides developers with basic control over text rendering and can guarantee layout consistency.
• For the end user
  • Can ensure that generated documents accurately reflect user input in the intended design.

Detail

1. Problem to be solved (Problem / Motivation)

Current Problem Points:

The TextSchema overflows the string from the frame, but there doesn't seem to be a way to prevent this in the pdfme.

I would like to Contribute, but there may be an idea that it should be a custom schema or Fork depending on the content, so I will post it in Discussion.

Specific Use Case:

I have set DynamicFontSize in TextSchema to allow users to type more characters (this is a very nice feature!!!).

However, I am having usability and technical challenges when creating templates for official documents such as invoices, quotations, and contracts.

1. issue from the user's point of view

Over-extending the size of TextSchema to accommodate more text is not very practical for formal documents such as ledgers.

Therefore, an approach was needed that would allow DynamicFontSize to work, but still keep the text completely within the boundaries of the box.

2. Technical issues

It is “technically possible” to truncate or validate the string input to Template based on the number of characters or lines so that the input string fits within the frame.

However, since pdfme internally (pdfRender) manages the strings to be displayed as “lines,” duplicating the logic involved in PDF rendering resulted in poor performance with Rutime.

Furthermore, many other helpers and utilities are not exported from pdfme, so it is currently difficult to process and validate text using the same display decisions as pdfme by means other than Fork.

2. Proposed Solution

To solve this problem, we propose to “add an option to TextSchema to not display overflow strings”.

Specifically

• Add a flag (e.g. respectTextBounds) to TextSchema to not display strings according to the height of TextSchema.
• In uiRender, if this flag is enabled, set overflow: ‘hidden’ in the TextSchema container to not display strings that extend beyond the bounds.
• To avoid displaying truncated out-of-bounds text when this flag is enabled, we believe pdfRender would use size calculations to truncate out-of-bounds “line” candidates and then draw the borders and text via the pdfLib feature.

Advantages of this solution

• For developers
  • Provides developers with basic control over text rendering and can guarantee layout consistency.
• For end users
  • Ensures that the generated documents accurately reflect user input in the intended design.

3. Alternatives considered

In addition to this proposal, the following alternatives were also considered

Alternative: Implement a TextSchema wrapper for product use cases.

Reason not selected:

As mentioned above, this alternative was not selected because the logic of interest, PDF rendering for Input, is covered by the internal implementation.

It is possible to approximate text parsing and processing with Intl.Segmenter and pdfme/common so that the input string can be displayed as is, but the performance degradation and DynamicFontSize support made this difficult.

Therefore, we believe our proposal is the most balanced at this time.

I'd appreciate your feedback on this proposal.

If you agree with this direction, I'm happy to work on a pull request.

I found in general using tables but sometimes you need some custom logic.

Example:
You have customers you want to print in a list but this list contains a lot of customers and depending on the template you want to render the ones with payment more than 1000 dollars.

What i found is custom table that will give user

schema spesficiation

Example

User selects Custom table

in code user can defines their arrays
like let's assume user has 3 arrays that will be used they are

Customers
Products
Vacations

user defines them
Customer -> contains name surname phone and responsiblePerson
Vacation -> startDate endDate createdAt

this table we have will only has 1 row user will see and can't have more

and in this part user can add headers and reference values from the given schema

Example header for customer

Customer Name
Customer Surname

then user can go ahead and in the 1 row they have go

${customer.name}
${customer.surname}

// Optinally null and undefined behavior also can be added

and then goes ahead and writes json-rules-engine code directly given input field in the custom rules section in the table

with this custom rules we can spesify only render customer that starts with C or T etc...

With this assume that you have a transaction list that has 35 columns in your database and want to make so users can customize what is printed

You will define it and all its columns

User goes ahead and defines what it want maybe they just wants to show amount and currency and nothing more

they can just add them

add their own custom rules
like only show transactions that's bigger than 1000
then it's done user can configure what they want to render and the api doesn't need to change for anything user can do and render whatever they want however they want and we can configure it depending on our data

Maybe its vacations we can create it depending on our vacation data in code like i explained

Feature Request: Page Options for PDFme UI

With the current version of Pdfme UI, it is not possible to add a new page with:

• A specific size (e.g., A4, A5, etc.)
• A specific orientation (landscape or portrait)

Description of the feature

It would be awesome to add the ability to specify page options when adding a new page, such as:

• Page size (e.g., A4, A5, Letter, etc.)
• Page orientation (portrait or landscape)

This enhancement would provide greater flexibility and control over PDF creation within the UI.

Possible Solutions

• Add New Page Popup:
  When the user clicks "Add New Page," open a popup dialog styled like PDFme UI that allows selecting the page size and orientation before creating the page.
• Default Page with Editable Options:
  Create the new page with a default size and orientation, then provide a section in the fields sidebar where users can adjust the page options (size and orientation) after the page is added.