Currently, text printers only take one object's rect transform to use has continue input trigger (place on screen where we can click to continue dialogue messages). On some occasions having multiple triggers would be beneficial I think. To better expose my suggestion I made a quick diagram, hopefully it will help visualization.
This is a custom text printer I'm implementing on a mobile phone kind of chat system.
In RED is the phone's screen, it has a Scroll View children and in turn the scroll view's Viewport is the object used as continue input trigger. Essentially making the phone screen (and only the phone screen) clickable for continuing message interactions.
In GREY is a overlay I place in the background. It has a simple empty Image component with a black color and a bit of transparency to provide UI separation. The goal is to also add this object to the continue triggers and in practice the player could either click the background or the phone screen to advance conversation.
In YELLOW, at the bottom of the container, are some navigation buttons that should remain interactive.
Placing an empty game object at the bottom of the prefab filling the entire canvas (rendering it last and on top of everything else) and assigning it to the continue trigger would work but we would lose the navigation buttons right? Also the navigation buttons are Layout dependent so they must remain inside the Container in RED. This means that they can't be placed above the empty game object I mentioned.
Other suggestion would be making the Overlay rect transform the trigger but since it is in the back, clicking the screen wouldn't advance conversation and that's not a desirable behaviour.
I looked in the source code and I believe that implementing this would be trivial. In UITextPrinterPanel (class implemented by textprinters), ContinueInputTrigger property and continueInputTriggerfield would take a List<GameObject> instead of just a single GameObject component. Then on InitializeAsync() we would iterate through the list with a simple foreach loop and add them to the input manager. We would do the same on OnDestroy() to remove them.
Since I want to refrain from changing base framework's files and lose the progress on updates I will probably copy the UITextPrinterPanel, make my changes and inherit from the copied class instead. I'm not sure if this fits into the general design of future Naninovel additions (now that we are out of Beta, changes that break code might be frowned upon by users and this means that custom text printers would probably need to be updated, not too critical but still annoying) but I still decided to bring this up in case someone is in the same situation.