I am creating a report meant to be read/edited by MS Word. To do that I have created it from scratch and saved as .docx.
In this report I am including some images together with captions. All of the captions were added manually. Everything went fine, I have saved the document and closed Writer.
Now I want to put my hands on it again and, upon opening the report, this is what I am seeing:. Previously the figure was showing fine inside the text box (that inserting a caption creates). The text box is in the same position and size, but there appears to be a boundary over which it just displays white. I can reduce the figure's size inside the boundary of visibility, and a glimpse of the captions appears too .
Note that the red arrow disappears too.
Needless to say, I can not work on a 100+ pages document and then check again each picture, delete it and re-create it, check again the cross references and so on. I would much rather work with LaTeX, but I am required to deliver a .docx file.
I am working on Ubuntu 20.04, Libreoffice is updated to version 6.4.6.2 and the only plugins I have equipped it are TexMath and Zotero.
Thank you for your time.
I noticed the same thing. It seems to be an issue already in Libreoffice Writer between Linux and Windows. If you create a document on Linux with a cropped image and then open the file in Libreoffice on Windows the cropping of that image is already messed up. Happens to me with Libreoffice Version 6.3.5.2.
i followed this official example to use DropZone with Bootstrap theme, it works good in Chrome but i noticed a problem in Firefox for mobile, seems that it can't manage the multiple file addition, you can see it directly from the official example page, if you try to select more than 1 file per time (2 pics for example) the creation of the list fails, there is only one preview row with no preview image and 0 byte dimension text.
Here the example adding two pics in a single time:
Just updated Firefox for Android at 79.0.5 version(08/17/20) and the problem is gone, but is still present in the previous versions, it would be very useful to understand what it is related to.
I am creating a pdf document (via ColdFusion), but when I preview the rendered pdf in Firefox, I get the number "4" where my checkmarks are supposed to be (see photo below). When I preview the exact same pdf in Chrome or IE, I see the checkmark, and it all works perfectly!
I am pre-populating the pdf form fields (via ColdFusion session variables), and then rendering the pdf using the following markup:
<cfpdfform source="82040.pdf" action="populate">
<cfpdfformparam name="org" value="">
</cfpdfform>
Here is the resulting pdf form in Internet Explorer:
Note how the checkmark is rendered properly:
Here is the same form previewed in FireFox:
Note how the the checkbox has a "4" instead of a checkmark:
Any help would be greatly appreciated!
It is a bug with Firefox's PDF Viewer. Currently, there is no fix. As radiovisual's post points out, the bug in the underlying library (pdf.js) was supposedly fixed. However, there is still the issue of Mozilla updating the older version baked into Firefox (which is what most folks are using). Currently, that bug is still outstanding.
Probably the best you can do is to return the pdf as an "attachment", rather than "inline", so the browser prompts them to "open/save" the file. If the user opts to "open" the pdf, it should open with their default program instead. (Adobe Reader is the default for most users).
<cfheader name="Content-Disposition" value="attachment; filename=fileName.pdf">
<cfcontent type="application/pdf" .../>
Update:
This bug was apparently addressed already, as pointed out via the project's github repo: the bug was supposedly fixed during this commit. So if you are still experiencing problems, it either means:
You are using an outdated version of the pdf.js library,
Or, the problem has been re-introduced into the library.
So to start things off, you will want to make sure that you are using the most up-to-date version of the pdf.js library. If you are still experiencing problems, even with the most up-to-date version, then the problem is still within the embedded pdf document viewer, and there aren't too many things you can do to fix this until the project maintainer's finally fix the problem.
The issue you are experiencing (the reason why you are seeing a "4" where there should be a checkmark, is because the pdf.js library is using a special symbol font to render the checkmarks, but in problematic versions of firefox's embedded pdf-viewer the symbol font isn't rendering the checkmark correctly, so it shows a "4" instead of a checkmark -- because the checkmark symbol they are using in the custom font just so happens to be mapped to the number "4".
Similarly, for the same reasons cited above, if you assign the checkbox to render squares (instead of checks), the letter "N" will appear in the checkbox instead of a square, because the square shape symbol is mapped to the letter "N".
This problem only exists in the embedded pdf document viewer in Firefox but will look perfectly normal when viewed in Adobe Acrobat Reader, or other offline pdf readers (and other browser pdf readers, which is why it looks fine in Chrome and IE), so when users download the form, it will appear like you would expect it to.
Some workarounds / optimizations you could try:
Try one of these, or all of these, they are in no particular order (or guaranteed to work)
Don't rely on the built-in pdf.js browser extension in firefox, instead, make your own updated version based on the latest pdf.js source or target another pdf library and use it's browser-agnostic API to render and display your pdfs.
Create an HTML form for the user to fill and verify all the information, then render the pdf based on the data supplied by the HTML form, for download only (no previewing in the browser). This will force them to open the pdf in their default pdf viewer where the issue is not present, because, again, the problem you describe only happens in Firefox's embedded pdf viewer and not in other pdf viewers like Adobe Acrobat).
Make sure you have the ZapfDingBats Font installed on your server. I haven't confirmed this, but that commit that was supposed to have solved this issue seems to have added support for this font, so it is worth a try to make sure this font is accessible on your ColdFusion server, then try previewing the rendered pdf in Firefox.
Detect that the user is accessing your form via Firefox, and if so, warn the users of the issue, but assure them that downloading the form and viewing in their default pdf viewer will work as expected.
Convert the page to HTML5 (if you aren't already), then add in an HTML5 shiv (so HTML5 features can be used on older browsers), and a CSS normalizer, and test if the problem persists using these optimal settings. It's worth a shot to make sure that the problem is somehow treated differently under the HTML5 standard, since not everyone is having the same issues as you.
Lastly, make sure that your HTML is being rendered as valid markup via your ColdFusion output by using an HTML validator.
Other than that, there isn't a whole lot you can do until the mozilla team updates their embedded pdf viewer. But since the problem is only in the firefox viewer, and not in the pdf itself, it it up to you to decide if this is a deal-breaker or not, and search for alternatives.
Note: PDF.js is built into version 19+ of Firefox.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Update: You can use this pdf (which represents the character mapping of the ZapDingbats symbol font) as a way of testing your browser's interpretation of embedded fonts in the pdf rendered via pdf.js. Note that at the time of this writing, the above pdf does not display the Zapf Dingbats properly in Firefox (via pdf.js), but other browsers render them just fine (notice the "4" next to a20[x2714] in firefox, and the checkmark next to the same entry (a20[x2714]) in Chrome.
I need to work on multiple PDF files and because of annotating those files, I prefer to use Preview built-in app for Mac OSX.
If I am in the middle of one PDF file say on Page 5, and I transit to some other PDF file and come back to the previous file, then I always get the first page of that PDF.
Is there any setting which I can use so that I always get the page from where I left?
Not sure what the problem is, mine works as you seem to want it to. Maybe your Preferences are set differently. Here are mine.
I am currently writing an application working with specially prepared image data. Another tool prepares the images (basically PNGs with additional data stored in the meta-data section). Now my tool works with these files, but not with all PNGs, so "we" decided to use a different file extension. So far, so good.
Now, because I am a lazy sack I implemented some file type registration to allow double-clicking on the file and opening it in my application (no problem at all).
And here is my Question:
It would be cool if the windows explorer could still show me the thumbnail previews for my files. Since they basically are still PNG files, it should be possible without writing my own shell extension (at least I believe so).
I quickly tried to copy all registry keys and values from HKCR.png to HKCR.mInDat (my file name ext) and it worked. However, I would prefere knowning what I am doing ;-)
Which of the registry settings are responsible for the thumbnail preview control and which can I use to get the preview for my file types?
I tried to google it, but I failed, since it seems I am unable to come up with the right buzz-words to find the info I need. Please, help me.
Thank you!
Yours,
3of4
Simple:
[HKEY_CLASSES_ROOT\.apng]
#="apng"
"Content Type"="image/png"
"PerceivedType"="image"
[HKEY_CLASSES_ROOT\apng\shellex\{BB2E617C-0920-11d1-9A0B-00C04FC2D6C1}]
#="{3F30C968-480A-4C6C-862D-EFC0897BB84B}"