Summary | enscript output for diffs renders improperly |
Queue | Horde Framework Packages |
Queue Version | HEAD |
Type | Enhancement |
State | Resolved |
Priority | 1. Low |
Owners | |
Requester | kevin_myer (at) iu13 (dot) org |
Created | 11/24/2005 (7197 days ago) |
Due | |
Updated | 12/02/2005 (7189 days ago) |
Assigned | |
Resolved | 12/02/2005 (7189 days ago) |
Milestone | |
Patch | No |
State ⇒ Resolved
MIME_Viewer objects, but I used the headers_sent() check that was
already in srchighlight.php and put it into all of the source code
viewers. I also moved all of the styles into the Horde stylesheet to
make the HTML a lot shorter/simpler.
variable in the html mime viewer.
tag instead of the a tags? That should save us a bunch of code.
generate a 1x2 table, can't the common style elements be pulled all
the way up to the table tag? For instance, font-size, font-family,
and line-height are the same for all entries and things seem to work
if I remove them from the td style tag and just stick them under table.
tag instead of the a tags? That should save us a bunch of code.
Regarding external vs. inline mime viewing: see the $attachment
variable in the html mime viewer.
New Attachment: MIME-source.patch
As far as the other issue, which essentially amounts to Horde
generating a HTML fragment (no header, just table data), how would you
propose to resolve that? Within the viewer context, is there a way to
determine if its being invoked to display something inline?
but it breaks inline rendering of mime parts.
And the line height problem might be solved with a fixed line-height
value in CSS, did you try that?
I can see how throwing a header into the middle of an inline rendering
will break things. I was only looking at fixing a specific problem,
without looking at all the ramifications of the fix.
A fixed line-height might do the trick. I'll see if there's a way to
solve it through CSS.
State ⇒ Feedback
but it breaks inline rendering of mime parts.
And the line height problem might be solved with a fixed line-height
value in CSS, did you try that?
see it even with the attached patch. Click on the patch to bring up
the viewer and notice that by the last line, the text displayed is
offset by about one line from the actual line numbers.
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ enscript output for diffs renders improperly
Queue ⇒ Horde Framework Packages
New Attachment: MIME-enscript.patch
State ⇒ New
patches, contains elements that cause the viewer to render poorly in
different browsers.
In Internet Explorer, if you view a patch/diff, the line numbers are
correct, but all text is rendered on the first line by IE. If you
send the proper header, the text renders on the proper lines, except..
For any browser, the lines of text do not match up with the line
numbers. For small patches, this is not a problem, because the
cumulative offset of the lines vs. the line numbers may not be that
great. But its noticeable in larger patches. After finally figuring
out how this all works, it came down to the fact that enscript adds
bold and italic tags to the HTML it generates (which is what its
supposed to do). However, those tags cause the respective lines to
render slightly larger. So for that issue to be resolved, the bold
and italic tags need stripped. The obvious tradeoff is you lose bold
for additions in a diff and italics for location line numbers.
However, if you keep the bold and italics, the line numbers on the
left are pretty much useless.
I think this patch puts things into a more useful state - color syntax
highlighting is intact, and line numbers match, but at the expense of
bold and italics.