htmlize/Hrvoje Niksic

htmlize/Hrvoje Niksic

[Phillip Lord]

Perhaps this is not the best place to ask, but does anyone have a
current contact for Hrvoje Niksic?

I've written a patch for htmlize (which allows me to specify the output
colours independent of Emacs current colour theme). But the main git is
down and he is not responding to the xemacs.org address given in htmlize
itself.

Phil

Re: htmlize/Hrvoje Niksic

[Uwe Brauer]

>>> "Phillip" == Phillip Lord <phillip.lord@russet.org.uk> writes:

   > Perhaps this is not the best place to ask, but does anyone have a
   > current contact for Hrvoje Niksic?

Did you ask on xemacs beta, or Stephen Turnbull directly? I have not
seen Hrvoje for years on xemacs-beta though.

Re: htmlize/Hrvoje Niksic

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

On Jan 10, 2016, at 05:26 PM, Phillip Lord wrote:

>Perhaps this is not the best place to ask, but does anyone have a
>current contact for Hrvoje Niksic?

He's been active on python-dev fairly recently.

https://mail.python.org/pipermail/python-dev/2015-November/142226.html

Cheers,
-Barry

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: htmlize/Hrvoje Niksic

[Phillip Lord]

Barry Warsaw <barry@python.org> writes:

> On Jan 10, 2016, at 05:26 PM, Phillip Lord wrote:
>
>>Perhaps this is not the best place to ask, but does anyone have a
>>current contact for Hrvoje Niksic?
>
> He's been active on python-dev fairly recently.
>
> https://mail.python.org/pipermail/python-dev/2015-November/142226.html

Ah, cool, thank you!

Phil

Re: htmlize/Hrvoje Niksic

[Vivek Dasmohapatra]

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 ]

Patches for htmlfontify (was Re: htmlize/Hrvoje Niksic)

[Clément Pit--Claudel]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On 01/14/2016 12:27 PM, Vivek Dasmohapatra wrote:
> 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 ]

htmlfontify is great, thanks for that piece of code!

Are you interested in patches? I have had an extension of htmlfontify in my personal source tree for a while (at https://github.com/cpitclaudel/.emacs.d/blob/master/lisp/htmlfontify/htmlfontify%2B.el). It adds support for composition (making htmlfontify compatible with prettify-symbols-mode, for example).

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Patches for htmlfontify (was Re: htmlize/Hrvoje Niksic)

[Vivek Dasmohapatra]

> htmlfontify is great, thanks for that piece of code!

GLad it's of use :)

> Are you interested in patches? I have had an extension of htmlfontify in 
> my personal source tree for a while (at 
> https://github.com/cpitclaudel/.emacs.d/blob/master/lisp/htmlfontify/htmlfontify%2B.el). 
> It adds support for composition (making htmlfontify compatible with 
> prettify-symbols-mode, for example).

Absolutely. Send it along to me - I've got a fix for the currently-broken 
invisibility support which needs feeding to the main tree as well.

Re: Patches for htmlfontify (was Re: htmlize/Hrvoje Niksic)

[Vivek Dasmohapatra]

> Absolutely. Send it along to me - I've got a fix for the currently-broken 
> invisibility support which needs feeding to the main tree as well.

Or I could just grab it from github - obviously I haven't had enough coffee 
today...

Re: Patches for htmlfontify (was Re: htmlize/Hrvoje Niksic)

[Clément Pit--Claudel]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

On 01/14/2016 12:43 PM, Vivek Dasmohapatra wrote:
>> Absolutely. Send it along to me - I've got a fix for the currently-broken invisibility support which needs feeding to the main tree as well.
> 
> Or I could just grab it from github - obviously I haven't had enough coffee today...

:)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Patches for htmlfontify (was Re: htmlize/Hrvoje Niksic)

[Clément Pit--Claudel]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On 01/14/2016 01:08 PM, Clément Pit--Claudel wrote:
> On 01/14/2016 12:43 PM, Vivek Dasmohapatra wrote:
>>> Absolutely. Send it along to me - I've got a fix for the currently-broken invisibility support which needs feeding to the main tree as well.
>>
>> Or I could just grab it from github - obviously I haven't had enough coffee today...
> 
> :)

I should also mention that my copyright assignment is on file, so that shouldn't be an issue.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: htmlize/Hrvoje Niksic

[Phillip Lord]

 > 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 ]


Good question.

So, first, I didn't know about htmlfontify (or rather I didn't know what
it did, even though I changed it recently!). I found out about it a
couple of days ago on Emacs wiki, and was thinking of seeing whether it
would serve.

The second reason is that org-mode uses htmlize, and it was for use
within org-mode that I am interested. I don't know why it does this, esp
given that htmlfontify is available.

A quick investigation of htmlfontify suggests that it is missing two
features. I need to be able to publish using inline fonts, and not CSS
-- I need to produce HTML snippets that I am embedding in a page that I
don't control. And, in term of org-mode, it uses htmlize-region, which
at first glance htmlfontify lacks an equivalent for.

The display class feature you describe would be useful: at the moment,
running Emacs in batch generates the terminal fonts in html. But I'd
also like to be able to say "this face is this colour, this face is
that, and every other face just ignore". This is for when I am
generating HTML to embed in a page I do not otherwise control, with a
white background (I use dark).

Phil

Re: htmlize/Hrvoje Niksic

[Rasmus]

phillip.lord@russet.org.uk (Phillip Lord) writes:

>  > 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 ]

So just to understand correctly, would htmlfontify be able to chose
correct colors for a buffer even if run via batch mode where text is not
colored?  Or would it "just" allow be to match against a style sheet?

> So, first, I didn't know about htmlfontify (or rather I didn't know what
> it did, even though I changed it recently!). I found out about it a
> couple of days ago on Emacs wiki, and was thinking of seeing whether it
> would serve.

I also hadn’t heard of it before now...

> The second reason is that org-mode uses htmlize, and it was for use
> within org-mode that I am interested. I don't know why it does this, esp
> given that htmlfontify is available.

It would be great to have a built-in alternative to htmlize in Org.  Just
today I ran into the issue of not having htmlize bundled...

> A quick investigation of htmlfontify suggests that it is missing two
> features. I need to be able to publish using inline fonts, and not CSS
> -- I need to produce HTML snippets that I am embedding in a page that I
> don't control. And, in term of org-mode, it uses htmlize-region, which
> at first glance htmlfontify lacks an equivalent for.

Thanks for checking this.  I agree that CSS declaration support is
important (see org-html-htmlize-output-type).  BTW: what you mean by
inline fonts?

As for htmlize-region, I guess it’s easy to replace using
with-temp-buffer, so I wouldn’t worry about it from the point of view of
Org, though it’s really handy to have in any case.

> The display class feature you describe would be useful: at the moment,
> running Emacs in batch generates the terminal fonts in html. But I'd
> also like to be able to say "this face is this colour, this face is
> that, and every other face just ignore". This is for when I am
> generating HTML to embed in a page I do not otherwise control, with a
> white background (I use dark).

I know you don’t want to use external files, but if you can relax this
requirement you could generate a stylesheet with
org-html-htmlize-generate-css.

Rasmus

-- 
To err is human. To screw up 10⁶ times per second, you need a computer

Re: htmlize/Hrvoje Niksic

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]

>
> 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

[-- Attachment #2: Type: text/html, Size: 2629 bytes --]

Re: htmlize/Hrvoje Niksic

[Vivek Dasmohapatra]

> containing preprocessor statements. You will see that the preprocessor
> background is missing in the html output whenever the text has a foreground
> attribute.

Hm. Works for me. I'll have to do some more digging.

Re: htmlize/Hrvoje Niksic

[Phillip Lord]

Vivek Dasmohapatra <vivek@etla.org> writes:

>> containing preprocessor statements. You will see that the preprocessor
>> background is missing in the html output whenever the text has a foreground
>> attribute.
>
> Hm. Works for me. I'll have to do some more digging.

Also, this fails for me.

I've just pushed a fix to another issue where htmlfontify appears not to
be handling multiple faces and face inheritance correctly. This looks
like the same kind of problem.

Phil