I used the google doc to display the pdf file in web broswer. It was working fine before. Now it gives no preview available. Most of the time it gives the blank screen with no preview available but sometime it opens the pdf. However i noticed that if the size of the pdf is small, it works fine but if the size is a bit larger with 10-100 or more pages, the no preview is shown.
link:
https://docs.google.com/gview?embedded=true&url=http://trafficpolice.gov.np/traffic/uploadfiles/56a0e8156d4ea.pdf
code:
WebBrowser view = new WebBrowser();
view.setURL("https://docs.google.com/gview?embedded=true&url=http://trafficpolice.gov.np/traffic/uploadfiles/56a0e8156d4ea.pdf");
I've just tried to encode the & character to %26 and worked fine for my case.
I had the same problem, in my case, I enabled google drive api and add key attribute to my iframe:
WebBrowser view = new WebBrowser();
view.setURL("https://docs.google.com/gview?key=YOUR_API_KEY&embedded=true&url=http://trafficpolice.gov.np/traffic/uploadfiles/56a0e8156d4ea.pdf");
problem resolved after 1 day
In my case, pdf file name contained '&' character. Once I removed the ampersand char, problem solved.
Hope it helps someone.
I added this code to my web.config. Works every time after these changes.
<basicHttpBinding>
<binding maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" messageEncoding="Text">
<readerQuotas maxDepth="2000000" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
</binding>
</basicHttpBinding>
For those who are trying localhost. You CANNOT use localhost to view previews. You can tunnel port 80 with ngrok and then it will work.
I used object instead of iframe, works fine in my application.
Several things that may cause this:
The browser you are using to upload these files.
The size of the file you are uploading.
Password/Permission of the files are set to private.
Quick Fix:
It has been noticed that most of the users who encounter this have been using Firefox (3.6.6 in particular). Try uploading your files using IE8 and clear your cache.
This issue has been further discussed here.
Related
When I set response content type as Excel, the Open/Save dialog is shown twice , just on IE8. It works fine on other browsers (tested on Chrome/Firefox/Opera).
The code for setting response content type is:
response.setContentType("application/vnd.ms-excel");
response.setHeader("Content-disposition","attachment;filename=abc.xls");
I searched for solutions/workarounds. Turning off Smartscreen didn't help.
Also, another suggestion was to wait for 5-10 sec before clicking Save/Open. That too didn't work.
What's the cause of this? Are there any IE specific workarounds?
It's a pain but IE8 is still widely used by the users.
This is just a guess, but it could have something to do with the way Office (used to) embed itself in IE with plugins.
A workaround might be putting it in a zip file before sending it over to the user.
Fontastic.me is a website that let you upload svg files so you can use your icons as a font. I've used this site lots of times, but today I noticed the icons are not working on mobile anymore. They do work in the browsers on computer. I only noticed it today, it has always worked before.
You can use this link to test on mobile.
To me it seems like a bug in the Fontastic CSS generator: your page links CSS
https://fontastic.s3.amazonaws.com/8pMGtiqubDqmpbD4ER7hE3/icons.css
this contains last SVG fallback linked as
https://cdn.myfontastic.com/8pMGtiqubDqmpbD4ER7hE3/fonts/1446830181.svg#1446830181
the hash part of the URL must correspond with font ID in the SVG, but actual source contains <font id="cloud-font" horiz-adv-x="512"> instead.
So replacing #14468301 with #cloud-font in CSS or replacing #id value in SVG should fix your problem.
This applies only for case your mobile really resorts to SVG version. Only few browsers would do that (I think Android below 4.4, maybe old Safari, Blackberry, and maybe Opera Mobile).
(Besides that, your HTML contains extra HEAD tag with icon CSS link in BODY, what is not valid. I donʼt think this will make any sane browser completely ignore the link, but cannot exclude such possibility. If you have served your page as real application/xhtml+xml, browser should show the error right away.)
Greg, i had the same issue. I end up ditching Fontastic and use https://glyphter.com/ instead.
Glyphter creates your own font set by uploading each character at a time.
It worked for me and perhaps you can try this too and see if it works.
I need to embed PDF files in an xpage application. We are using IE11 x64 and this cannot be changed. Eventually, I'll also need to embed MS Office files (Word, Excel, Power Point).
I have looked at a lot of pages and couldn't get a working solution for this... I have some code that works if I force IE11 in IE10 mode, but then Dojo starts acting weird (cannot close dialog boxes, ...).
The code I have right now in my computed field looks like this:
var id:string = pageDocument.getDocument().getUniversalID();
var attNames = #AttachmentNames();
var url = getAttachmentURL(id,attNames);
'<object data="' + url + '#view=Fit&pagemode=none&statusbar=0&messages=0"' +
'type="application/pdf" width="100%" height="100%" > ' +
'<p>It appears your Web browser is not configured to display PDF files. ' +
'No worries, just click here to download the file.</p>'+
'</object>'
I need a free solution.
IBM, This should be made easy if we want to compete with SharePoint, no???
Short answer: don't bother.
Long answer: While you might get it to work for PDF in IE11, your boss won't be happy, because it will not show on her iPad, so you need to have a plan B.... and there is another gotcha down the road (read below). This is what I would do:
Use Apache PDFBbox to extract text from the PDF and show that in the XPage.
Add a link to the page to open the whole PDF
Do the same thing for office documents using Apache POI eventually using OpenNTF POI4XPages
The download link should make use of WebDAV for Domino to allow round-trip editing
Why all this fuzz:
Your users will use mobile at some point of time and NO mobile browser does support embedding (nor do any browsers on a Mac)
Even if you successfully get embedding working, users will start to edit the embedded document and get really really upset since you don't save back the changes
On a side note: asking IBM to support a technology that is vendor proprietary working in one browser (that has been EOL for future updates - see project Spartan) - ain't going to happen.
I got this working nicely in IE11 for PDF files with this very simple line:
<embed src="MyPDFFile.pdf" width="640px" height="755px" alt="pdf" />
I'll go along with Stephen's answer: I won't bothe rtrying to mak ethis work with Office files. It will give our "Notes is bad" users some munitions to move to SharePoint, but we do have other advantages!
I tried using Bumpbox, and pdf.js and while I could get them working, iframes seemed to work best for me with using normal Domino attachment urls in xpages
I am not sure if this solution is right or not, but it works well for an app I have that only has PDFs. It does work on mobile too, at least on iOS.
<iframe
src="#{javascript:
var url = 'https://app.nsf/';
var doc = sessionScope.docID;
var atname = #RightBack(sessionScope.aname,'Body');
var end = '/$file'+atname;
return url+doc+end}"
width="800" height="1000">
</iframe>
Probably the best approach is to use a pure HTML5/JavaScript renderer
for PDF documents without any third-party plugins (e.g. PDF.js)
For further discussion take a look at the following stackoverflow
entry recommended way to embed pdf in html
In my opinion, it's the best way to use a commercial product (e.g. crocodoc) for other documents like MS Office (Word, Excel, etc.).
I have created a file upload function which saves all the uploads to a certain place:
private String destination = "D:/Documents/NetBeansProjects/FileUpload/uploadedDocuments/";
Is this a good place to store it? Should I store it some where else?
Is it possible that once the upload is complete for a page to be displayed showing the user what they have just uploaded, like a box below showing a preview? And how would I go about doing this? I am new.
I have figured it out how to display a plain txt file and an image, however it is the pdf that is confusing me.
As to the upload location, which seems to be the IDE project folder, that's absolutely not right. You should choose a configureable and fixed location somewhere outside the IDE project folder. You should not rely on using getRealPath() or relative paths in java.io.File. It would make your webapp unportable. See also this related question: Uploaded image only available after refreshing the page.
Whatever way you choose based on the information provided in the answer of the aforementioned question (and all links therein), you should ultimately end up having a valid URL pointing to the PDF file in question such as http://example.com/files/some.pdf.
Then, you can serve the PDF file on a webpage using either an <iframe>:
<iframe src="/files/some.pdf" width="600" height="400"></iframe>
Or an <object>:
<object data="/files/some.pdf" type="application/pdf" width="600" height="400">
some.pdf <!-- This link will only show up when the browser doesn't support showing PDF. -->
</object>
Keep in mind that showing PDFs in a browser is only supported in browsers having Adobe Reader plugin. Note that the <object> approach will gracefully degrade to a link when the browser doesn't support displaying application/pdf content.
I'm creating some pages using a SiteDefinition, the markup looks something like this:
<File Url="Page.aspx" Name="$Resources:SiteDefinitions,PageName;" Type="GhostableInLibrary">
<Property Name="Title" Value="$Resources:SiteDefinitions,PageTitle;" />
<Property Name="PublishingPageLayout" Value="~SiteCollection/_catalogs/masterpage/Somepage.aspx"></Property>
<AllUsersWebPart WebPartZoneID="WebPartZone1" WebPartOrder="1">
-- webpart data here
</AllUsersWebPart>
</File>
The page is created as expected, but it's somewhat faulty. If for instance I click Edit Page and then click Publish (without actually editing anything) I will get this error:
"This Page has been modified since you opened it. You must open the page again."
I will get this error approx. every second time I try an editing action.
If I manually create a page using the same page layout everything works as expected and this error does not show up.
Does anybody have an idea what could be wrong?
I too create a Page using the above method only thing I found missing in your code is that I used to have a title in the PageLayout as
<Property Name="PublishingPageLayout" Value="~SiteCollection/_catalogs/masterpage/Somepage.aspx, Your title"></Property>
This should not be the cause, but you can try it, Also refer the articles this or this
I think you're right with using PublishingLayoutPage. I came across this article today while searching for this error caused by something else. It describes your same issue although the person in the article was not inheriting from PublishingLayoutPage and had not specified the PublishingPageLayout property. When they fixed this it worked.
This doesn't directly help you, although I did notice in their article that they are specifying the ContentType property. Have you tried specifying this? As you can see your complete code, are there any other differences you see from the article or additional information from the comments?
Okay, I (kinda) got this working now.
The guy who had made the ONET.xml had put a reference to the page layout in the Url attribute of the element.
Like I wrote in a comment earlier I tried making the page layouts inherit from TemplateRedirectionPage. Instead I now made an empty default.aspx file that inherits from TemplateRedirectionPage and changed all my page layout files back to deriving from the PublishingLayoutPage. And then I added the PublishingPageLayout element below every element.
Funny, or oddly, having a refence to the page layout in the Url attribute and not having the PublishingPageLayout element at all is actually valid. It doesn't make sense, because it will produce these faulty pages, but SharePoint actually accepts it and spits out all the pages defined in the ONET.xml
Only thing left now is that since I made the above changes, when I manually create a new page based on a page layout every default webpart (as defined with AllUsersWebPart) is instantiated 5 times. Really don't know where this behaviour is coming from, but at least it's not as serious as not being able to edit/publish my pages :)