#Interactive forms

353 messages · Page 1 of 1 (latest)

slow mica
#

@charred willow

charred willow
#

Ty

charred willow
#

The tracking issue for interactive forms can be found here: #2421

The overall plan is to support interactive forms for PDF export in some way and at least provide a visual representation for non-interactive formats such as SVG and PNG. Once HTML export is it would add another export format which can support forms, once work on pdf-writer is finished I'd like to take some time to read up on the semantics of HTML form elements so that the typst implemenation isn't to PDF specific to ease the implemenation of HTML export ahead of time.

#

@slow mica could you rename this to Interactive Forms and pin the tracking issue message?

slow mica
#

Interactive forms

charred willow
#

Ty ❤️

bitter wharf
#

@charred willow will content groups be part of interactive forms? (i.e in the pdf-writer updates you're doing)

charred willow
#

No, I'm not sure how big the scope is there, they could be relatively simple or similarly complex, so I'd put them in a differnet PR.

bitter wharf
charred willow
#

If you think about picking them up shoot me a message i plan to do some work on the pdf-writer API before the next minor version since we already have a breaking change there

bitter wharf
#

I won't really have a look for while so it'll likely be merged before then!

charred willow
#

Yeah it only concerns styling for newly added APIs so they stay consistent

#

naming, documentation, etc.

charred willow
#

The worst thing about forms is that the spec is not clearly followed by most readers, yet the archaic PDFs Acrobat produces work

#

appearances are used to track state for radio buttons, i found that out after much trial and error

#

And now I'm trying to find out why i can turn off my radio buttons again when i explicitely set the flag to not be able to do this

charred willow
#

@bitter wharf did you ever peer deeper into pdf.js?

bitter wharf
charred willow
#

I'm debugging why my radio buttons don't work and it seems pdf.js is parsing them as checkboxes

bitter wharf
charred willow
#

chromium behaves similar

#

i have the exact same flags as the acrobat pdf

#

i can't figure out where pdf.js actually reads them

#

it does a whole lot of async event listening fuckery between reading and having acutal objects

bitter wharf
#

I have no idea either 💀

#

PDF.js is a tricky beast

#

other PDF readers (in C/C++) are much easier to read imo

charred willow
#

yeah but harder to debug

bitter wharf
#

I think your best bet is to see what GhostScript reads them as by teeling gs to print debug info

#

it's an unreadable mess

#

but it's likely your best bet

charred willow
#

I think I may have identified the culprit

#

this snippet returns undefined, and is then set to 0 if that is the case, so the flags are not correctly read

data.fieldFlags = (0, _core_utils.getInheritableProperty)({
  dict,
  key: "Ff"
});

The code seems to look directly in the object itself, then in Parent and so forth (makes sense) but Parent is indrect and such doesn't have this property???

#

i found the issue

#

sometimes it's just a silly typo

#

i was setting Tf, not Ff

bitter wharf
charred willow
#

idk what the 0 is doing there

bitter wharf
#

how are they calling a """tuple"""

charred willow
#

just calling it directly also works

bitter wharf
#

JS is such a weird language

#

Glad you found the issue ❤️

charred willow
#

now firefox renders them hella ugly because of my boxes

#

but they almost work, chromium keeps winning impl wise

bitter wharf
charred willow
#

So these are the valid states, with checkboxes firefox and chromium had the same behavior, check left or right would check both, doing the same again would uncheck both, checking middle would uncheck left and right

//  a   b   a
// [ ] [ ] [ ]
// [x] [ ] [x]
// [ ] [x] [ ]
#

chromium still does that but respects the no_toggle_off flag

#

firefox now thinks left and right are different buttons 🙃

#

why dos pdf.js respect the RADIOS_IN_UNISON flag for checkboxes, but not for radios?

(imagine red arrow pointing at the word RADIOS here)

charred willow
#

Dropdowns work too

charred willow
#

evince doesn't display my example document 😭 I've grown so used to readers highlighting the fields in blue, that I forgot that evince doens't do it at all

rustic ingot
#

(a, b) === b

#

but what's {dict, key: value}

charred willow
#

dict is the form field object

#

key the field to look for while waking up the parents

rustic ingot
#

but what's the syntax

charred willow
#

And it worked all fine I just had a typo in my field name

#

Anon object for keyword args I think, if the name is already bound you don't need dict: dict perhaps

rustic ingot
#

hm

#

seems odd

#

js has no kwargs

#

oh yup apparantly it's the same as dict: dict

charred willow
#

Ye

bitter wharf
#

What do you mean comma operator?

#

´Cause it’ll put me in a coma?

charred willow
#

You can probably do that in cpp too, it let's you override the comma operator

#

I think I have most of the functionality tested, I've only got appearances left

#

For some reason Okular will simply use it's own appearance even if I specify one

#

And I want typst to be able to output consistently good looking forms for almost all viewers

rustic ingot
charred willow
#

what on gods green earth, you're right

rustic ingot
#

also the default behaviour guarantees left-to-right evaluation, but any overloadable implementation provides no guarantees

charred willow
#

Ok I want some feedback, the screenshots I'm posting now are all of the same file made in acrobat reader, in this order: okular, evince, firefox, chromium, acrobat

image.png image.png image.png image.png image.png
#

we see subtle differences here, mostly in how input fields are styled

#

but others are more drastic like okular providing default appearances even if you have provided appearances yourself

#

the question is if I should try to fight okular here, or simply accept it

#

Fuck

#

Virtual box keeps bricking my pc, I hate testing in acrobat

#

okular, evince (😂), firefox, chormium

image.png image.png image.png image.png
#

you can see here that only chromium renders the very simple appearance correctly

#

acrobat is missing because my license ran out

#

chromium the only one actually displaying the push button's border too

#

could someone inspect this in acrobat, my vbox seems broken

📎 forms.pdf
bitter wharf
#

Oof some readers really do be struggling

charred willow
#

yeah, but getting tot he acrobat like output should be doable, it's just that it sets awhole lot of different things

#

sometimes it's appearance, sometimes appearance_characteristics, sometimes both depending on what it is

#

trying to make sense of the xobject streams is always fun

#

and why theirs works but mine doens't

bitter wharf
#

Does LaTeX support forms?

charred willow
#

I'm not sure

#

hyperref packages supports forms

bitter wharf
#

ugh it's so ugly 🤢

charred willow
#

I'm also wondering how much of forms should built in, it'll definitely be a subset of the full functionality, something that is not "built in" by the spec itself, but supported by acrobat is date fields by using a very specific text field action

charred willow
bitter wharf
charred willow
#

We'll make ours pretty!

bitter wharf
charred willow
#

I'm thinking that the fields will be simple transparent constructs like a link

#

and the actual styling is simply the element inside it

bitter wharf
charred willow
#

this should be especially helpful for buttons

#

like radios being just

# 
#let on-appearance = // 2 circle paths
#let off-appearance = // 1 circle path
#radio(
  radio.button(on: on-appearance, off: off-appearance),
  radio.button(on: on-appearance, off: off-appearance),
  radio.button(on: on-appearance, off: off-appearance),
)
#

and automatically take grid layout or somthing like that

#

i think if we get ancestry by then this would make the API very powerful

#

othewise we'll go by keys for identifying related buttons

bitter wharf
#

but won't that cause an issue with layout?

#

like both on and off need to have the same size 🤔

charred willow
#

well

#

yeah

#

or no, we could take whatever is larger

#

too early to say

#

the size is set on the annotation rect

bitter wharf
#

Will this start being in for 0.11 or is it more of an 0.12-0.13 thing?

charred willow
#

not sure, depends on how early 0.11 will come

#

I'm testing appearances but i have trouble understanding what is needed to get it to look right

#

it seemed that a text with an alternate appearance set would not have any appearance, but only default appearance worked

#

and like you saw above, the appearance i have set only works in chrome, so something is still off

#

Ancestry would be so cool for this

# 
#radio(name: "radio", required: true, default: "a")[
  My cool radio buttons:
  #grid(columns: 2,
    radio.button(option: "a"), [Option A],
    radio.button(option: "b"), [Option B],
    radio.button(option: "c"), [Option C],
  )

  More of those:
  // more radio buttons in different layout
]
#

we could cheekily look up the ancestry to find the enclosing radio element

bitter wharf
#

I actually think we could have ancestry today

#

with laur's new way of measuring depth we could "rework" it to track ancestry

charred willow
#

Also funny enough

#

Scoped styling rules the way typst had them perfectly model how fields can inherit things from their parents

#

So we can maybe just skip the extra radio element and simply set the key for this scope

#

This is both convenient and allows for the maximum flexibility the spec allows (buttons being related even when they're pages apart)

reef root
shadow hearth
bitter wharf
old sigil
carmine robin
charred willow
#

I pray for their wellbeing then

charred willow
#

No year, new commit on pdf-writer#25

bitter wharf
#

No year sounds terrifying

charred willow
#

no

#

typo

odd lark
#

mew

#

:3

charred willow
#

Good news, I finally found time to work on forms again and already made some progress, I've decided to largely ignore viewers which do not properly handle appearances mainly because:

  • they are not very widely used
  • people who do use them don't care too much
  • the most used viewers do actually accept my form appearances (namely chromium, i assume so does adobe, but testing this on linux is not that easy, for some reason my vm regularly crashes my host)
charred willow
#

(evince remains unimpressed)

I wonder if chrome is simply more permissive and accepts my incorrect appearances, or if evince is super pedantic or both

charred willow
#

Works ✅

#

I thought i messed it up, but that's just how okular renders it it seems.

#

Marked the pdf-writer PR as ready for review, specifically the example for forms need some polishing and I think this is the time where some of yall could chime in to see what you would want to have explained.

shadow hearth
charred willow
#

Almost all the forms I opened in it are rendered incorrectly

fickle elk
#

@charred willow Any updates on this? No pressure, but I'm just really excited for that feature in Typst excited

charred willow
#

hah that's funny

#

I'm on the review

#

pdf-writer is almost finished

fickle elk
charred willow
#

essentially, but first I'll get back to the drawin board on how they should look from the typst side, how mcuh we can meanigfully expose to the user and so on

fickle elk
#

does this include js support?

#

I think some PDFs use this to make the forms interactive, but I'm not too sure if that is really needed ASlaugh would be a big problem for HTML export later though xD

charred willow
#

yes, at least to some degree

#

it allows embedding scripts which are used for example by acrobat to allow a date picker form

#

that's not a natively supported form field, but acrobat makes it work using a very specific js snippet

#

and if we generate the same output we can do that too

low sentinel
#

How is this going, I saw the pr was reviewed. But not much after. Looks like the compatibility is pretty weak between viewers.

charred willow
#

The team is currently on holiday

charred willow
low sentinel
slow mica
#

@charred willow if forms are done, we can release pdf-writer 0.10 soon. it really needs to get out of the backport-to-0.9 hell.

charred willow
#

Yes it was merged by reknih earlier today

#

It should be

slow mica
#

for Typst to be able to use pdf-writer 0.10, we'll unfortunately also have to re-release svg2pdf (still with an old usvg version), which is a bit of a hassle, but oh well

charred willow
#

I have opened #4174 to get the discussion started on export target specific code. See also #1239578999664152699.

quaint jasper
#

sub-targets, such as PDF/A-2 support #2942 are not easily accounted for unless they receive potentially useless sub-elements like pdf.a2 or pdf.x

I'm not sure whether this should even be exposed on the Typst side, IMO PDF/A2 should be something that is handled completely by the Typst compiler

#

I think being able to distinguish between png/pdf/svg should be sufficient

#

or what's your rationale behind exposing this?

charred willow
#

Likely, I can't say i know what exactly the requirements are

#

but i know it's a subset which must adhere closely to the standard

#

a package which uses some low level features could panic on incorrect usage with a nice error message

quaint jasper
#

I don't think we should give that much low-level access to a package to potentially break a certain PDF compliance. If the user sets his export mode to be PDF/A-2 or whatever, then the Typst compiler has to verify/make sure that this compliance holds, a package should not be able to "break" out of that if you know what I mean

charred willow
#

Yeah i think that's fair

#

But interplay of some features could in theory provide better error messages

#

we should likely discuss this in #1239578999664152699

quaint jasper
#

oh whoops I thought I was in there 😂

slow mica
#

@charred willow btw, not sure what the state of this is, but Typst is on the latest pdf-writer version now, with your PRs landed

charred willow
#

Ah good to know

#

I'll draft some ideas on Sunday or so

fickle elk
#

Do you think initial support will arrive for 0.12 or later?

charred willow
#

I don't know when 0.12 is coming, so I can't say for sure, I'd say later simply because there are some other blockers still like output targets

charred willow
#

Something I'm unsure about in relation to this is how we should name and structure form elements, I've thought about a few different ways to do this, but non of them seem satisfactory so far, I'll create an issue for this soon and post it here too.

charred willow
#

Things I have deliberately left out for now are: JS actions, bush buttons and signature form fields (not yet implemented in pdf-writer)

shadow hearth
#

(e.g. switching appearances depending on hover)

Could you use optional content groups for this?

charred willow
#

I'm unsure, I haven't looked at what they can do

#

this is another feature where one would need to consider the export target

#

and how these are represented for other targets, if at all

#

the biggest problem is PNG and SVG export being the main export types used for webapp and typst-preview, although i believe the typst-preview SVG export is not the typst one

#

we need to at least show consistent representations for those two

#

so avoiding such behavior could be a valid option to ensure this

rustic ingot
#

hmm, how do you preview interactive export...

#

I'm tempted to say use html export to preview interactive pdfs

#

😖

#

although I found Zathura with the poppler plugin was rather responsive with recompilation on type

#

idk if it supports forms

#

but maybe that means compiling and displaying pdfs in real timeis viable

charred willow
#

I mean it's definitely fast, and I assume forms are more common in short documents

shadow hearth
#

Does the actual interactivity need to be previewed?

charred willow
#

It's definitely helpful

quaint jasper
#

I think that would be pretty hard to do for png export

#

I think as long as you can see the form elements it should be enough

shadow hearth
charred willow
#

yes

#

not something i planned on implementing for now

#

it would also be out of scope of what i work on

#

I work neither on typst-preview, nor on typst.app

slow mica
#

@charred willow I had a thought regarding sys.target: We might need the mechanism to allow for local changes. E.g. in HTML export we could need a way to layout some piece of content (e.g. a figure) with Typst's layout and produce an SVG. So maybe we need some contextual mechanism.

charred willow
#

This sounds like it is relevant for document embedding too

#

i.e. embedding typst document within another one

#

You should add that to the issue or PR so we can discuss it there and get more input

slow mica
#

will paste it there

exotic prairie
#

I am super interested in this being a feature within typst 🙂

#

Is it at the point where there is a alpha/demo of this feature?

charred willow
#

Anyone is free to contribute, I don't have time until mid to late october when I'm done with my masters thesis

exotic prairie
#

What is left to do?

charred willow
#

The typst side impl of export and the elements

#

The pdf features are merged, all but signature fields that is

#

I heard Ana is gonna work on that

slow mica
charred willow
#

Yeah

paper scarab
shadow hearth
charred willow
#

I don't know, I only heard that this was what she was working on

#

In the last community call I believe

carmine robin
carmine robin
#

Hello! What's the status of this endeavor? I'm asking because.. oddly enough, a lot of people are interested.

#

@charred willow are you still on it?

shadow hearth
carmine robin
#

Yes! Maybe it will be picked up again? I also vaguely remember it being done in the pdf-writer but not in typst or something.

charred willow
#

All of this is true I intend to pick this up in the next week

paper scarab
#

nice

#

looking forward to it, and just recently first experienced the need for it

charred willow
#

@slow mica (not urgent) from the recent html sneak peek I saw that you went the route of having low level export specific elements that get wrapped by native elements (table -> html.tbl, even if not yet fully implemented). So I figurd I'd start with this on the forms side, where did you put the html element and did you already work off of the shatter PR?

slow mica
#

if you want I can push it, though the diff against main is horrible

#

maybe I'll just merge shatter now

charred willow
#

nah, I'm working off of shatter and just wanted to know where to put the pdf element/module to avoid having to do copious amount of rebasing

slow mica
#

I created typst-library/src/html/mod.rs for the elements itself and typst-html for the HTML generation logic

#

I think there will be an HTML category in the docs

#

Because there is just enough stuff

#

Not sure whether the same would pull its weight for PDF, but maybe

charred willow
#

if we had more pdf stuff maybe

crisp fog
slow mica
#

usually, I'd go through all my changes again, but on this one it doesn't seem feasible. let's just hope I didn't screw anything up.

image.png image.png
charred willow
#

OCGs are sought after for example

slow mica
#

Should there be a 0.12.1 with cherry picked bug fixes, backporting will sure become interesting...

#

But I don't want to be held hostage by a potential patch release

crisp fog
quaint jasper
#

Wasn’t there a pretty big issues with circles/ellipses?

slow mica
#

yes

#

but seems like nobody uses it, because nobody noticed 😂

#

I think git would probably handle most backports just fine since many files just moved

#

and other than that, backporting just the most crucial stuff manually would probably not take more than a few hours

charred willow
#

my god RA is slow rn

#

i thought it was supposed to be faster on shatter

slow mica
#

*except if you are in typst-library, then just a bit

charred willow
#

true

#

but it feels somehow slower than before

slow mica
#

maybe you just didn't open it for a while?

#

it got steadily worse over time

charred willow
#

perhaps, yeah

slow mica
#

I imagine that a lot of the slowdown is due to the macros

#

when I'm reworking that stuff for value & content unification, I will put more emphasis on less bloat via macro

#

I think just the #[elem] on HeadingElem expands to ~1000 LoC

#

so, the macros are not probably not slow themselves, but they just generate way too much code

#

ouch, all PRs got conflicts now. I would have hoped that it deals better with the moves.

#

well, that's life

crisp fog
#

my local pixmap branch too :(

#

well, tomorrow I have time

slow mica
#

but I'd hope that git rebase will still just do it?

crisp fog
#

I still don't quite like it anyway

charred willow
slow mica
#

yeah I know but rebase & cherry-pick can still deal with them in principle

charred willow
#

github seems to also give up on trivial conflicts a lot

crisp fog
#

well jj at least did not deal with them

slow mica
#

yup, if I go to a simple PR and type git rebase it just does it

slow mica
charred willow
#

ty, no worries

charred willow
#

@slow mica I gathered a few questions:

  • Which pdf export phase is the most appropriate for writing a bunch of top level dictionaries into a PdfChunk? They are referenced in the catalog /AcroForm entry and in a page dictionary's /Annotation dictionary. EDIT: It seems that write_page may be the most appropriate place, as this is also where link annotations are written, see below.
  • I'm wondering how I best get information about forms from typst::Content to typst_pdf::write_frame. I figured, maybe I'd add a new FrameItem, since the enum seems to be an appropriate place to have annotations (since links are also anotations and are there too), but this also sort of assumes that layouting is done for these when I'm only caring about the semantic information of form fields (where they are on a page, what kind of options they have, yadda yadda).
  • Somewhat related to the second question, since links are anotations and so are form fields, perhaps it's best to make this a single AnnotationItem? It seems that LinkItems handle both the content they refer to (writing the link text) and the annotation that enables the interactive behavior which seems to be what I need for forms too.
slow mica
charred willow
#

I don't have much yet because I'm unsure where to start, there's plenty of code that I've never touched

#

But yes, the annotations need to know their bounding boxes among other things

charred willow
#

The gist of what i had in mind:

  • we traverse pages and encounter a form field somewhere on that page
    • if this is a terminal field, then it must have a position and size and most likely has things that actually need to be rendered (by the viewer, not by us)
    • if this is a non-terminal field, it does not have a position or size and is only used for grouping, it doesn't need to be displayed
  • rinse and repeat, do other page specific writing too
  • we finish the page and write all annotations (terminal fields) into it's annotation dictionary (similar to how link annotations are written at the moment)
  • rinse and repeat, for each page
  • we finish the doc and write all root fields into into the catalog

For those non-terminal fields, this mainly happens if we have radio buttons, as these have a parent field which refers to the actual buttons you can press, depending on the API on the typst side for radio buttons we may never need to emit this invisible kind of form field.

slow mica
# charred willow <@311948531835469827> I gathered a few questions: - Which pdf export phase is t...

It seems that LinkItems handle both the content they refer to (writing the link text) and the annotation that enables the interactive behavior which seems to be what I need for forms too.
Maybe I'm misunderstanding, but the FrameItem::Link only contains the link, not the linked text.
but this also sort of assumes that layouting is done for these when I'm only caring about the semantic information of form fields (where they are on a page, what kind of options they have, yadda yadda).
But if you need bounding boxes, shouldn't there be some layouting?

charred willow
#

Maybe I'm misunderstanding, but the FrameItem::Link only contains the link, not the linked text.
Ok, I must've mixed up some parts in the code then, but they're still slightly different, because we don't seem to currently add any stylistic things to links where ever we handle FrameItem::Link, even though annotation dictionaries would allow us to do so in the case of widget annotations (used by forms).

But if you need bounding boxes, shouldn't there be some layouting?
I guess so, but it's nothing we don't already do otherwise really. Most fields are simply block level elements and should ideally use the same mechanism block uses. I haven't looked into layouting so I don't know how exactly that would work.

slow mica
odd lark
#

Wha the latest on this :3

shadow hearth
#

I don't think there's any news

charred willow
#

Been a bit swamped at work, but I promised myself that I'd work on this first if I have anytime for open source

bitter wharf
#

Even if it's all very enjoyable

charred willow
#

Motivation is at an all time low as well

shadow hearth
#

I just realized that if we ever get proper pdf import then typst could conceivably be used to fill in existing forms too!

charred willow
#

I already haev enough anxiety as is

shadow hearth
shadow hearth
#

didn't mean to cause anxiety

charred willow
#

i was jesting

#

tyty

charred willow
#

Since it has been quiet in here for a while, I wanted to clear up what has been happening and why this isn't done yet.

Recently I found the time to work on FOSS stuff again, but I've often times looked at the feature and couldn't really find a good starting point (even with Laurenz's suggestions). This lead to me procrastinating the feature. I've also felt stressed out about not working on it whenever I had free time.

While I don't have any obligation to work on this I wanted to apologize for the feature taking so long anyway. After all there are people waiting on this.

The more I look at it, the less I want to work on this, meanwhile other projects like my uni template (used by some colleagues at work who are doing their theses) and typst-test need more of my time to be released and production ready.

So, in order to no longer block potential contributors, who could be working on this in the meantime, I want to officially withdraw from working on the feature. I may come back to this if no one else works on this and I find the time, but for now I won't work on it.

I'll post this on the tracking issue to make it clear that this is open to contribution and I'm happy to share my experiences with the different readers regarding forms support and quirks to anyone who wants to make this work.

shadow hearth
#

Is your existing work on it public?

charred willow
#

All work on pdf writer was merged, yes

#

I haven't really found time to start on typst itself

#

Since everytime I tried I didn't know where to start and got lost reading and understanding typst itself before it was already midnight

#

The good thing is that the remaining work can be seen as the exciting part of the feature, i.e. adding the actual elements

drowsy quiver
#

I'd love to give this a go, but I'm currently graduating. I'll have time starting February.

I'm not very confident in my skills so don't let this stop anyone else from working on it.

drowsy quiver
#

Welp I do not think i've got time for this. My masters is taking up more time than I anticipated.

charred willow
#

Yep that was my experience too, good luck on your studies!

drowsy quiver
loud hill
#

So what's the current status quo on this? I won't say i have time to take over the whole thing, but at least a few people around me are very interested in it.

As far as i interpreted https://github.com/typst/typst/issues/2421
We have everything ready to implement interactive forms in PDFs per se, just Typst's side of implementation is missing?
https://github.com/typst/typst/issues/4368 seems(reads?) pretty straightforward, but actually nothing can be done before
https://github.com/typst/typst/issues/4174 ?
I'm currently rumbling through the later, but it seems dormant since July, last year. Has there been work continued/moved somewhere else?

shadow hearth
#

The status quo is that nothing has happened

charred willow
#

We have everything ready to implement interactive forms in PDFs per se, just Typst's side of implementation is missing?
That's correct, but I don't know if krilla (the new PDF backend) supports this out of the box

#4174 is actually already partially there, there is a html element that serves as inspiration for the pdf counter part and the target() function exists already

#4368 would be the logical place to start at

loud hill
#

Oh, ok. I haven't checked on Krilla yet. I'm currently looking for the supposed sys.target discussion on the discord 😄

#4368 would be the logical place to start at
I am not sure if understand yet how those features are supposed to work without #4174, but i appreciate the pointer.

shadow hearth
#

This seems like a daunting first issue to tackle @loud hill 🙂

loud hill
#

That's correct, but I don't know if krilla (the new PDF backend) supports this out of the box
I haven't seen anything decisive on the question yet, besides the obvious inheritance of pdf-writer features. I assume @slow mica isn't the other Laurenz as well?

shadow hearth
#

No, that would be @quaint jasper

charred willow
#

The krilla author is @quaint jasper

#

Whoops

quaint jasper
#

I have not implemented anything relating to forms

loud hill
#

Thanks, sorry for the pings

loud hill
#

@quaint jasper i started to look a bit further into it. Would you like to add/merge forms features in
krilla/src/interactive/forms.rs
or rather be put somewhere else?

quaint jasper
#

That sounds like a reasonable location

shadow hearth
quaint jasper
charred willow
#

the one in pdf writer yeah

#

never touched krilla

shadow hearth
#

Is krilla built on top of pdf writer? Edit: yes

loud hill
#

@charred willow is there a reason your pdf-writer example doesn't include appearance streams?

charred willow
#

I think I tried around with them and just couldn't figure out what was going on

#

But they should work similar to how they work with any Annotation

loud hill
#

They do, mostly. I just went from "Oh, Krilla is actually a great layer for those" to "Wait why aren't they used where i would expect them?".

keen canyon
#

following this thread because i wanted to make a pdf with forms today! discord only pins threads to the channel list if i post a message, even if i don't have anything to say, sorryyy

charred willow
#

Or by clicking the follow button

keen canyon
#

clicking follow didn't work for some reason

#

like it didn't pop out into the channel list, and it only did so when i put a message in

humble island
#

that's because the thread is inactive. if you're followed, It will pop out for you once there is activity again @keen canyon