doc viewer text inputs change default to text-align: RTL

[Danny Mendel]

hi Mat

how are you?

can you share with me the "right" way to configure a custom default behavior for viewer inner document textbox inputs ?

i tried the obvious

$(document).on('documentLoaded', function () {

....

window.innerWindow.$('input[type="text"]').css({

                          'text-align': 'right',

                          'direction': 'rtl'

                        });

didn't work

when added a small timer, just to experience if it has to do with the fact that input render was not ready instantly after "documentloaded" has been fired. so ->

$(document).on('documentLoaded', function () {

....

window.innerWindow.$('input[type="text"]').css({

                          'text-align': 'right',

                          'direction': 'rtl'

                        });

$.wait(4000).then(function () {

                        window.innerWindow.$('input[type="text"]').css({

                          'text-align': 'right',

                          'direction': 'rtl'

                        });

seems to reveal that indeed, the input render comes much later, perhaps another event handler can signal the right timing to handle change to styles, but before user actual see the first glimpse of the loaded content (and inputs)

it applied OK BUT just to the current /active display page control, moving to other page

needed shows that it had no effect on ALL of document inputs as i want to achieve offcourse

so can you kindly share with me the right way to manipulate all inputs in ALL pages with a needed css styles via

1. javascript like i had been trying

2. hard coded css file -> trying to add change ReaderControl.css following rule

input, select {

    vertical-align:middle;

    direction:rtl;

    text-align: right;

}

didn't make any change, stil remains left-align, i suspect the CoreControls.js handle the css rules with dynamic js manipulation.

many thanks

Danny

[Matt Parizeau]

Hi Danny,

You can use the pageComplete event to be notified when a page is ready and you'll be able to access the input elements. See this post for an example of how to use the pageComplete event https://groups.google.com/d/msg/pdfnet-webviewer/t1yonOZzRSU/bCwAsHq2AwAJ

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[Danny Mendel]

PageComplete is not a good idea for my need.

as i need this RTL behavior when scrolling a multi page pdf.

i believe this pageComplete event is called only ONCE you focus on specific page

via select a page thumbnail and/or click on particular field.

and not when you just look at screen using the vertical scroll.

i was looking for Pre-render event for the entire page, and couldn't find one.

also i understand i can not even modify a static css markup as those fields are build on the fly

inside the CoreControls.js internal engine, correct ?

Danny

[Matt Parizeau]

Hi Danny,

The pageComplete event should be fired whenever a page is finished rendering, even when scrolling. What version of WebViewer are you using? There was a bug in WebViewer 2.2 that caused issues with this (https://groups.google.com/d/msg/pdfnet-webviewer/A4dn7uvB2m0/ZLvutDutCAAJ). If you update to the build in that link or WebViewer 2.2.1 then does it seem to be working better?

If you're still having trouble could you provide a sample and describe the difference between the actual and expected behavior.

Thanks,

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[Danny Mendel]

Hi Matt,

i'm using latest 2.2.1 with your latest published modification i think it is WebViewer_2.2.1.52425 (18 NOV?)

i prepare a quiick movie who show you exactly what i was witness and wrote down.

again the idea is to have a consist behavior of allways have pre-configured a RTL/Text-Align to right behavior regardless your use scroll, toggle pages, click/focus into a field or leave it out.

as you can see in my movie, i couldn't solved this challenge with your above suggestion, perhaps i'm missing here.

any way take a look here -

https://www.maspick.co.il/files/a4ed530d-bd70-4e46-8167-046db88126a8/bda4ed530d-bd70-4e46-8167-046db88126a8.webm

many many thanks

Danny

[Danny Mendel]

hi Matt ? hope i find you well any suggested solution for me ?

cheers,

Danny

[Matt Parizeau]

Hi Danny,

The problem is that you have your code on the outer html page and not inside a config file like the sample code is expecting. This means that when you use $ to select the elements it's only trying to select the elements on your outer html page, not inside the iframe.

You'll need to first get a reference to the iframe's jQuery and then use that to select elements. For example:

var inner$ = $('iframe')[0].contentWindow.$;
inner$('[id^=pageWidgetContainer] div').each(function() {
  ...

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[Danny Mendel]

hi Matt,

you wrote

"The problem is that you have your code on the outer html page and not inside a config file like the sample code is expecting. This means that when you use $ to select the elements it's only trying to select the elements on your outer html page, not inside the iframe."

the code i'm using is

window.innerWindow = $("iframe[src*=WebViewer]")[0].contentWindow;

myWebViewer.instance.docViewer.on('pageComplete', function (t, e) {

window.innerWindow.$('[id^=pageWidgetContainer] div').each(function () {

    var $this = $(this);              

      $this.find('input[type=text]').css({ "direction" : "rtl", "text-align" : "right"});

  });

});

can you please explain why do you think my code is different from your suggestion ? for me it seems identical.

and i manage to get access to whole iframe inner objects, 

via window.innerWindow.$('[id^=pageWidgetContainer] div').each

nothing to do with "outer html pae"

please take a look at my video and above detailed explanation,

in short again,

i think the pageComplete event doesn't triggered when you use scroll,

and i also think that your suggested selector [id^=pageWidgetContainer] div' only return objects which are displayed under an active page (for practicum moment the pageComplete triggered - when first page shown or use select another page, but not when user scrolls up/down), 

i need a solution which i can modify ALL fields, in ALL total pages, regardless what is been shown right now, right after doc has been loaded.

this solution should be by code, but it will be also interesting to hardcode it via css, which i didn't manage to do either as i believe the pdfnet js engine modify text-align:left property internally. (after custom css applied)

attached the file again 

thanks

Danny

[Matt Parizeau]

Hi Danny,

Sorry you're right, the code you're using should be applying the CSS and actually does seem to apply it when I test it. If you try debugging inside the pageComplete event you should see that the code is hit when the page is first added to the DOM and on subsequent changes. Currently we don't have a nice hook into overriding the styles so the pageComplete event needs to be relied on. After typing in the field we are reapplying the original styles which is why the alignment changes. We will likely add an easier way to do this in an upcoming version.

For now you could use a CSS class and add !important to the end of the rule to force it to be applied over the inline styles that WebViewer applies.

input[type=text] {
    text-align: right !important;
    direction: rtl !important;
}

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[Danny Mendel]

hi Matt,

first, thank you for your quick reply.

just to summarize:

1. hardcoded/fix solution works! - applying input text properties with !important (inside ReaderControl.css) works as you suggested

2. dynamic solution via code ? i understand your explaination regarding the current limitation of pageComplete, but i didn't get your response to the fact i need to modify fields for other flows, such as scrolling, where as pageComplete is not called at all.

is there any "hidden" event i can handle after doc has been loaded and i can access/apply ALL fields in ALL pages, so scrolling up/down will happen after i had manipulated those fields first ?

if i could find this type of "pre-render" event, i could try to apply "important!" dynamically perhaps to bypass the above limitation you mentioned.

many thanks

Danny

[Matt Parizeau]

Hi Danny,

The pageComplete event should be fired event for scrolling and it behaves this way for me when I console.log every time it's called and then scroll through the pages. Note that it's only fired when the page finishes rendering, i.e. complete. I'm not quite sure why it isn't working for you.

One thing about the dynamic solution is that you can apply !important rules, however when editing the field the original style will be set back on the element since they're both being set as inline styles. For now I think the hardcoded CSS is probably the better solution.

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[Danny Mendel]

hi Matt,

very strange, we get different results,

please check this movie 

as you can see thumbnail page selection , or navifate via normal next/prev buttons works as expected, but in my case scroll up/down never trigger completePage at all.

are you sure it works for you ? i'm using this attached pdf, converted to XOD (via server side pdftron C# lib) , and i'm using latest published webviewer (WebViewer_2.2.1.49365.zip)  w/ "xod" format 

via this following standard options:

var options = {

          type: "html5",

          path: "WebViewer/lib",

          serverUrl: "annotationHandler.aspx",

          documentId: this.sync.syncmap[0].Value,

          documentType: "xod",

          enableAnnotations: true,

          useDownloader: true,

          showLocalFilePicker: true,

          mobileRedirect: false

        }

can you double check please  with above pdf/settings ?

many thanks

Danny

[Matt Parizeau]

Hi Danny,

Thanks for the video. One thing I noticed is that you're logging the current page and you'll notice in your logs that it logs some pages twice (the little two beside it). WebViewer may render multiple pages close to the current page so you should actually be logging the second parameter in the pageComplete callback, in your case this is "e". When you do this you'll see that multiple page numbers may get rendered as you jump around.

The reason why you're not seeing pageComplete fired when you're scrolling is because everything is already in the DOM so we're not needing to trigger the pageComplete event again. The reason it does fire again when clicking on the thumbnails is just an implementation difference behind the scenes with setting the current page number. When you jump like this we're getting the page from the cache so it's quite fast but it triggers the pageComplete event when it does this.

If you try loading your document and scrolling all the way to the bottom without clicking the thumbnails you'll see that there is a pageComplete event fired for pageIndex 3 (number 4).

Matt Parizeau

Software Developer

PDFTron Systems Inc.