Did you try a compiled app?
Good job @TIMAI2, great PDF reader!
updated to v2.3 to provide file access in Kodular
- added page count property
- added page clicked returns page number to webviewstring
- added scroll to page number from webviewstring
- developer must set webviewstring = 1 when first displaying pdf
- no requirement to reload pdf when changing scroll to page
Now included is an add on extension to allow selection of Assets when the app is compiled. The method used to do this is to write(copy) the asset file to a temporary file in the private directory of the app (there doesn't really appear to be any other way at the time of writing). The temporary file is overwritten when a new asset is loaded. You must ensure that your file naming follows the standard format, e.g.
You can download the add on extension and see the usage/blocks in the first post.
Hi @TIMAI2 , hope you are having a good time, I wanted to ask that, what block fitts in the web viewer socket in this block if we want to open a specific PDF.
I would be highly grateful if you answer this question
check 1st post, there is sample blocks there.
for the pathToPdf, please make it accept string like '//test.pdf' for from assets, and 'test.pdf' for from ASD, thus the user will no need to join string for full path manually.
drag a webviewer component into designer and then go to webviewer block and scroll to the extreme end and drag that block out and put it inside the webviewer parameter
This is done on purpose, to give the developer the freedom to set the filepath, and to remove the opacity of "built-in" file paths and the peculiarities of the file scopes. Admittedly, I did have to provide the helper extension for the assets path when compiled.
Then it's better to accept both relevant path and full path.
Is there any developer like to joint full path with more blocks?
me, I do
You are welcome to work on the source if you wish....
Working for me nice extension
Hi how to change background colour i want to white background but even i am changing colours it not working
Are you using the latest version of the extension ?
Did you follow the example blocks in the first post ?
Show your relevant blocks...
Just tested, all working OK here:
In response to a developer loading (or being unable to load!) a 312 page, 2.5mb PDF file, I have created a second extension that can handle such long files (as well as the shorter ones). intest the developer's PDF crashed out (memory problems) at @ 100 pages. For safety, I set the range limit to 50 pages.
This extension has a helper block that get the count of pages, then returns page ranges in batches of 50, along with a final remainder range. Blocks are then required to allow an end user to iterate over each range, viewing the resultant pdf for each. The main ViewPDF block now has a startPage and endPage socket, which are used, in iteration to apply the page ranges. This block can be used on its own for smaller pdfs, set the startPage to
0 and the endPage to
-1. This extension retains the same interactive features as the original, and can also use the ViewPdfAddOn extension for assets when compiled.
- Latest version: 2.4
- Tested: tested on App inventor 2 (n188), in companion (2.62u) and compiled modes on Android 10 and Android 12.
- Released: 2022-05-19T23:00:00Z
- Last updated: 2022-05-19T23:00:00Z
- Built: using the RUSH Extension Builder by @Shreyash
- A clock component is used (set at 250ms) to ensure the progress dialog is shown before the pdf range is generated.
- Developers could add a Previous button to show the previous pdf page range, or just call a single page.
uk.co.metricrat.viewbigpdfV1.aix (19.1 KB)
Enjoy , and all feedback, comments and questions welcome.
Available for use in any MIT AppInventor projects or competitions
There is quality problem while zooming in, cant read some texts
Also can i remoove or hide additional page number (page 1,page 2)
another problem is that when set to white background it displays a green shade ( not a big problem )
We are at the mercy of what the pdfrenderer can achieve, coupled with the standard of the source material. Practicalities of keeping the image output to a reasonable size also come into play, otherwise generating a "better image" of a page will slow down or crash the device, even for one page.
Set the colour of the page text to the same colour as the background.
Try a different white? Or this could be device related, or related to the original pdf.