ticket	summary	type	release	owner	status	created	modified	_description	_reporter
12958	Rendering issue in ticket when aligning side by side 2 pictures	defect	1.0	ursaw	new	2016-11-17T15:25:09+01:00	2016-11-17T15:25:09+01:00	"If I use the align parameter with `left` and `right` values for juxtaposing images, they overflow the frame of the ticket and compress the following elements in the middle empty space.[[BR]]
Not sure if it's related but I have modified the default CSS style in order to expand to the max the width of the ticket content.
{{{#!css
#content.ticket {
        width: 100%;
}
}}}"	ntmlod
10358	Resolution of image after convert is horrid	defect	0.12	ursaw	assigned	2012-09-21T20:23:51+02:00	2012-09-28T08:40:56+02:00	"The resulting png file produced is of very low quality.
I recommend a modification adding -density 300 or a configurable density before input pdf path & name. The default convert uses produces a very ugly and almost illegible png.


"	anonymous
10004	support of pdf file ressource path for Apache location	enhancement	0.11	ursaw	new	2012-05-03T14:34:37+02:00	2012-09-28T09:04:07+02:00	"Since my Apache webserver {{{ 192.168.1.10 }}} also offers a location {{{ /Foo }}} (which is a mapping to another network resource), I can access pdf files in the browser by typing {{{ https://192.168.1.10/Foo/example.pdf }}} in the address line of the browser. Also {{{ [//Foo/example.pdf My PDF file] }}} works as Trac link.

Now I want to use this path for !PdfImg
{{{
[[PdfImg(//Foo/example.pdf)]]
}}}
but it just gives me the following error:
{{{
Error: Macro PdfImg(//Foo/example.pdf) failed
Der Anhang 'wiki:WikiStart: //Foo/example.pdf' existiert nicht.
}}}"	falkb
9874	PdfImg macro runs with 100% cpu load	enhancement	0.11	ursaw	new	2012-03-02T12:17:00+01:00	2012-07-25T21:59:02+02:00	"Displaying PDF files with many pages leads to an internal call of {{{ convert }}} which can last very long (a few minutes). During this time, my Windows server was fully charged to capacity (100% CPU load) by the parallel process of that call of convert.exe. Convert.exe is also very memory hungry and after a few moments the whole RAM was allocated by convert.exe. This is critical for a responding Trac service, all web interface reloads tend to suffer from timeouts.

You should set a priority below ""normal"" for the external call of convert.exe, and maybe limit the memory for that process."	falkb
9875	calling PdfImg macro for PDF files of many pages takes very long	enhancement	0.11	ursaw	new	2012-03-02T12:22:48+01:00	2012-03-02T12:22:48+01:00	A few minutes can go by until the Trac page is processed and displayed. As you cannot speed up the external tool 'convert' you should either warn about a long response time at runtime or limit the call of PdfImg to a maximum number of pages. Otherwise users are frighten off why displaying by PdfImg is that slow, although Acrobate Reader loads the same PDF file in 1 second.	falkb