Hi Sean,

The important thing to note is that when Forms generates a PDF, all input fields except for radio buttons and checkboxes are generated as div elements without the input field.

As a result, any CSS targeting input, textarea, or select elements will not work because the HTML content for the saved PDF is not the same.

There's a few ways to address this:

Use the Field Id for the CSS

Instead relying on the parent and element type, target the field directly. For example, if your parent element is targeted with #q41, then for anything other than a table the field id should be #Field41.

The same id is applied whether it is an input or read-only, so that should work in both scenarios.

#Field41 {
    /* your css here */
}

Add more CSS selectors to cover the read-only version

The HTML structures stays pretty much the same; the input is converted to a div element, but the rest is mostly left alone, so you can target the child of the div with the cf-field class.

#q41 input,
#q41 .cf-field > div {
    /* your css here */
}

Or you could just have it increase the font size of anything that is an immediate child of the div element with the cf-field class.

#q41 .cf-field > * {
    /* your css here */
}

Try to override the default CSS

The default font size is set by CSS classes within Forms, so you could just add the same selectors to try and override it with your own (I haven't tested this with a saved PDF yet).

#q41 input,
.fl-component .submission-view {
  /* your css here */
}

That second selector is pulled from the default Forms css and applies in read-only view, which in previous versions was mostly the same as the version used to generate a PDF.

One of the easiest ways to test stuff like this is to create a user task with the "read only" check box selected, then assign it to yourself to see if it does what you want.

The read-only copy for a user task should be pretty close to what is used for the PDF so you can test your CSS and stuff like that more easily.