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 ...
Related
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.
I'm trying to display a .pdf file on a browserfield but somehow it's not opening in my app however it works fine with .txt files.
I'm reading .pdf file from local storage and using
browser_field.displayContent(fileinbytes, "application/pdf", "");
but it's displaying a player like image on the screen and not actual result.
If anyone has any idea about the same, i'm all ears.
As far as I can tell this isn't possible (browserfield doesn't even fully support javascript).
This post suggests that you can view it via Google, which wouldn't be from local storage.
(Un)luckily blackberry is very similar to Java ME, so you can often use those libraries as is. Apparently JPedal can render pdf files for J2ME, and might be worth a look.
Other than that, I don't think you'll have much hope. Good luck
Need help on rendering PDF using CGPDFContext. I am currently using UIWebView to display PDF but would like to perform much more operation rather than just reading like Highlight Text, Search PDF, Annotate PDF. Not looking for using any Framework or library.
Any help will be beneficial. For a start, code on how to render PDF using CGPDF and displaying it instead of using UIWebView.
PDF annotations are a rabbit hole. I've been working on them since 2010. The spec is thousands of pages. It's easy to get started but it takes forever to get right with all the PDFs and variations out there. Even a simple feature like bookmarks are harder than you would think.
To date there's no open source framework that implements PDF annotations. The above linked one can be a good starting point. If you don't have months/years to build something on your own, there are a few commercial options available - like PSPDFKit, available for iOS, Android and Web, which I am building.
We have a guide article listing the most important PDF spec documents.
Searching is another tricky topic. It's quite hard to convert the PDF text data to unicode. The Adobe CIDFont spec is a good starting point.
You shoud try VFReader, it is an open source project for rendering PDF files on iOS. It can be a good starting point.
is there anybody out there, with experiences about how to do a gantt-diagram / chart using latex.
I tryed it for a lot of hours today, lastly it worked switching outpout from pdf to dvi.
Maybe someone can tell me what to include, besides pst-gantt, and the normal pstricks stuff.
It showed more than 100 errors for 4 Tasks.. after switching to dvi there was a big 0.
i am using the whole distribution mitex .. upgradet to the newest version. stupidly i have the error log not avaible on this computer. but it was always the same error. i was using pst-gantt, outload missing packages.. hm errors will follow tomorrow morning
Reading the pst-gantt README it looks like this depends on the pstricks package. I believe that the "ps" is for postscript and the functionality is implemented by generating DVI "special" commands; which means that you can't produce output pdf directly using pdflatex. You can get to PDF output, but you must go by way of DVI. Either source->DVI->PDF or even source->DVI->PS->PDF.
I came across this question when having trouble with pst-gantt and pdflatex. As others have pointed out you need to go via DVI, which honestly sucks if you have used pdflatex all the time.
So I did some search, and found this phantastic replacement written by Martin Krumm: http://www.martin-kumm.de/tex_gantt_package.php
Is it possible to search "words" in pdf files with delphi?
I have code with which I can search in many others files like (exe, dll, txt) but it doesn't work with pdf files.
It depends on the structure of the specific PDF.
If the pdf is made of images (scanned pages) then you have to OCR each image and build a full text index inside the PDF. (To see if its image based, open it with notepad and look for obj tags full of random chars). There are a few utilities and apps that do this kind of work for you, CVision PDF Compressor is one that I have used before.
If the pdf is a standard PDF, then you should be able to open it like any other text file and search for the words.
Here is page that will detail some of the structure of a PDF. This a SO post for the same.
The components/libraries mentioned in the answer to this question should do what you need.
I'm just working on a project that does this. The method I use is to convert the PDF file to plain text (with pdftotext.exe) and create an index on the resulting text. We do the same with word and other office files, works pretty good!
Searching directly into pdf files from Delphi (without external app) is more difficult I think. If you find anything, please update here as I would also be very interested in that!
One option I have used is to use Microsoft's ifilter technology, this is used by windows desktop search and many other products such as sharepoint and SQL server full-text search.
It supports almost any office/office-like file format, even dwg, msg, pdf, and files in zip/rar archives.
The easiest way to use it is to run FiltDump.exe on any files you have, and index the text output.
To know about the filters installed on your PC, you can use ifilter explorer.
Wikipedia has some links on its ifilters page.
Quick PDF Library's GetPageText function can give you the words from a PDF as well as the page number and the co-ordinates of those words - sometimes useful for highlighting.
PDF is not just a binary representation. Think of it as a tree of objects, where an object node has some metadata and some content information. Some of these objects have string data, some don't. Some of these are even encrypted, and some are compressed. So, there's very little chance your string finder will work on any arbitrary PDF.