Re: htmlize/Hrvoje Niksic

[Anders Lindgren]

Out of interest, was there a particular reson or feature which led you to use htmlize rather than htmlfontify (which has been merged for a while)?

[ I am curious as I wrote htmlfontify, which can already choose the colours
  emacs would use for a different display class, which sounds similar to
  what you are describing here ]

Hi,

sorry for jumping in to this discussion.

Some time ago I was faced with the same decision when developing my highlight2clipboard [1] package (a package that ensure that highlighting is retained when copying from Emacs to other applications). There were many reasons I went with `htmlize':

 * I only wanted a html snipped, without a head, so the inlines-css output method provided by htmlize was better for my purposes

 * htmlfontify includes a _javascript_ section in the output, which was something that really I didn't want

 * htmlfontify includes too much detail, like the font I'm using inside Emacs -- I only wanted color and style information like "underline".

Also, I just ran htmlfontify and htmlify now to compare the end results and discovered that if fails to handle the case when faces overlap, e.g. when one face provide the background and another provide the foreground. To test this, you can install my preproc-font-lock [2] package, enable it using `preproc-font-lock-global-mode', and run htmlfontify on any C file containing preprocessor statements. You will see that the preprocessor background is missing in the html output whenever the text has a foreground attribute.

In addition, the result buffer is associated with a file and marked as "not modified", despite not being saved to the file system. A better solution is to ensure that the buffer is marked as "modified" so that the user can save it using C-x C-s.

[1] https://github.com/Lindydancer/highlight2clipboard

[2] https://github.com/Lindydancer/preproc-font-lock

Sincerely,

    Anders Lindgren