| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
|
| |
pdftohtml will use the file path as the basis for generating the
image links in the generated HTML, so we want them to be relative,
not absolute. Ruby 1.9 tempfile.path will generate an absolute
path when given the current directory as the tmpdir, whilst 2.0
and 1.8 will use a relative one.
|
| |
|
|
|
|
|
| |
We want the HTML to be encoding in the default encoding so that
it can be combined with other strings.
|
| |
|
|
|
|
| |
Fixes https://github.com/mysociety/alaveteli/issues/1563
|
| |
|
|
|
|
|
|
|
|
|
| |
Sometimes pdftohtml will generate thousands of images when converting an
image embedded in a PDF. This causes a request spike when a user tries
to view the converted PDF as HTML.
See https://bugs.freedesktop.org/show_bug.cgi?id=77932 for the bug
report.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
TODO: We really should be testing the full output of RTF#body, but we currently
want to remain consistent with Adapters::PDF as many methods are shared between
the Adapters.
A more correct spec might be:
expected = %Q(<font size=3><font color="#000000">thisisthebody</font></font>)
adapter.body.should == expected
|
|
|
|
|
|
|
|
|
|
|
| |
TODO: We really should be testing the full output of PDF#body, but
inconsistencies between pdftohtml prevent sensible means of doing this.
For example:
adapter.body.should == %Q(\n<A name=1></a>thisisthebody<br/>\n<hr>\n)
Fails because some versions (correctly!) use lower case tag names.
|
| |
|
| |
|
| |
|
| |
|
|
Extracts the attachment processing from FoiAttachment#body_to_html
AttachmentToHTML contains adapters which convert
- text/plain
- application/pdf
- application/rtf
Results are returned as an AttachmentHTML::HTML instance which contains
the raw HTML and other metadata about the conversion.
|