ticket,summary,type,release,owner,status,created,modified,_description,_reporter
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
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