I'm generating a markdown document using my Rails 4.2 app which includes images that are on the same server (in the public folder).
Using pandoc (pandoc-ruby 1.0.0), I want to convert the document into various formats, especially HTML (to preview it in the browser) and DOCX (to download it).
The preview in the browser works perfect. But when converting to DOCX, the images aren't included. I guess this is due to multiple requests to referenced images while pandoc is generating the document.
I have already experimented with setting allow_concurrency to true, but this didn't solve the problem. Also, it happens on both the development and the production environment (while in development, it takes a long time, and in production it doesn't - maybe due to some differences in timeout limits?).
I have already found a way to solve my problem by not referencing the images using an URL, but by embedding it as base64 string into the document. But this for sure can't be the solution of choice, as it tends to bloat up the HTML document a lot. Also, on production, I already get RuntimeError (Stack space overflow: current size 8388608 bytes) from pretty small embedded images. So I have to find a real solution.
Reference the images by file path instead of url if they are on the same server.
Related
In my application, users can change the background image of a banner. They upload the file using Simple Form and Active Storage. It's working correctly but we had a user trying to upload a file name banner-website.png (2).png. The file is uploaded and saved but doesn't appear as a background image. I guess this happens because of special characters in the filename.
What is recommended to avoid such situations? Do we need to sanitize file names?
Several things to check:
Check the console and tried to view the CSS and see if the full link
is being populated? Try checking the CSS code and copy the link to
an address bar to see if the image loads from that direction.
Check the users png file to make sure its not corrupt. PNG headers that are corrupt can cause issues displaying in a website.
Check to see if your sanitizing plugin is causing an issue with that file. I have never used that one so regarding that I cannot say.
I tried uploading a file with a same name into my Rails 6 testbench (vanilla with active storage and stimulus js) and it works fine. It could be a conflicting CSS code too.
Just my 2 cents.
I've found the solution here: Rails Active Storage - Background Image invalid property?
Adding a single quote around the URL solved it.
I have a Ruby on Rails back-end service that takes individual PDF documents and combines them into a consolidated PDF - app uses Wicked-PDF ruby gem for generation.
When the PDF is viewed through the browser's default document viewer for PDF, the full document is visible. However, when the document is downloaded and viewed through Adobe Reader or Acrobat, only a part of the document will be fully rendered and then I receive an error "Problem reading this document (14)" with all of the remaining pages turning into small blank thumbnail-like pages, almost like it is corrupted - however, it is not corrupted because it is fully viewable in the browser.
The error has occurred on multiple documents in inconsistent locations, so it seems like it might be related to the particular document being compiled into the full PDF document, but haven't been able to isolate the cause.
Has anyone else encountered this issue w/ the Wicked-PDF package gem?
We identified that the issue was actually in the combine_pdf gem we were using to do the document compilation. The error is caused when two or more documents share the exact same content, ie. they are the same file, regardless of their file name. We are now commparing each document to all others before compilation to ensure that it will not generate an error.
Of late, I have observed that pdf generated by latex files are unreadable in certain email browsers (when previewing the attachment in Outlook) as well as the printed hard copy especially math symbols like inner products, integral etc overlap with each other making the file ugly and unreadable. Surprisingly the same file looks perfectly fine when viewed using the ShareLatex built-in pdf browser as well as the desktop version of Adobe Reader.
ShareLatex documentation suggest switching the PDF viewer from built-in to native. Upon changing to native, even the browser version had unreadable characters.
[https://www.sharelatex.com/learn/Kb/Changing_PDF_viewer]
So, I would like to know if there is better way to compile the tex file in Sharelatex so that its readable across platforms and in print.
Most of the "pdf generation from tex" related issues posted on StackOverflow point out problems with viewing images. As such the pdf files I am generating don't contain any images.
Thanks in advance !
AFAIK there's not a single build-in PDF viewer (browser, e-mail client, ...) that works well. But what you could test is if \usepackage{lmodern} makes things better ...
I am using transloadit to generate a thumbnail image sent from an iOS app that saves both the original image and the thumbnail to Amazon S3. The files get get saved out correctly with one exception. The file name for the thumbnail does not retain the capitalization of the original filename for the file extension, i.e. JPG vs jpg. Here is my template:
I am using the fields to generate the custom path I want--which works fine, however, the output from the "store_thumb" step has this difference:
Is there any way to retain the capitalization? I realize I can just force all of my filenames from the app to lowercase, however, I thought maybe I am just doing something wrong. Any suggestions?
I'm part of Transloadit's developer support team.
First of all, let me assure you there's nothing wrong with what you're doing. Secondly, I've asked our engineers about the issue and we realized it's a limitation caused by our special usage of some of the conversion tools.
We'll do our best to address this on future versions, but we cannot commit on a date. So for now if it's causing you trouble, we recommend using lowercase letters.
For a rails app that works a lot with uploaded image heavy pdf files I'm looking for a way to optimize the file size of uploaded pdf's.
Adobe Acrobat has a 'save as reduced file size pdf' option which often halves the filesize when images are included.
I would like to do a similar action that is triggered after a file upload in my rails app.
Any ideas?
While #lzap's comment may be true, if you still want to give it a shot, you might look at pdftk (PDF Toolkit). Its a library for manipulating and creating PDF files that looks like it offers the ability to compress a given pdf file.
The library can be installed on most major operating systems, so if you have the ability to install it on your host, then simply call:
system("pdftk uncompressed-input.pdf output compressed-outpu.pdf compress")
inside your rails app whenever you want to compress a particular PDF file. I have no idea how long this would take, and if you are compressing many PDF's at the same time, you may want to consider handing off to a background job (without this, Rails will wait until the compression is done before returning anything to the browser, probably causing a timeout error for long running groups of compression calls).
Also, if your file names come from user input, be extra careful to avoid injection attacks.