[libcroco-list] Some library user feedback...

[Bjoern Hoehrmann <derhoermi gmx net>]

Hi,

  I am about to release a first attempt at building a libcroco-based
CSS Validator and in writing it I found the following problems with the
library. I would like to hear opinions on how they can and should be
addressed.

  * CRTerm.unary_op and CRTerm.the_operator appear to be design bugs;
    essentially thanks to them libcroco cannot handle declarations like
    foo: / /; or foo: , ,; or foo: / + bar; and they complicate how I
    process the property value; I think they should be removed and the
    tokens should occur simply in the ->next chain under some special
    or general term type.

  * libcroco lacks automatic encoding detection based on the @charset
    declaration (or so I read on the list). What I would like to have
    would be a public routine that I can pass a buffer, which would
    then tell me whether there is a proper @charset rule and if, what
    encoding it declares. I can then transcode the buffer myself and
    pass a proper UTF-8 encoded buffer to libcroco for the actual
    parsing.

  * The IO and transcoding routines are somewhat dated and in fact a
    bit broken, I gave an example earlier on the list where it runs
    into an infinite loop trying to decode a ISO-8859-1 encoded doc
    as UTF-8; this should never happen. I think there are some glib
    routines that could replace much of the current code. I also note
    that IO is apparently the main bottleneck, performance improve-
    ments there would be very welcome. Perhaps it might make sense if
    there is a way for the caller to gurantee the input is perfectly
    valid UTF-8, then some of the normal checks could be skipped.

  * It seems there is currently no way to let higher-level apps take
    care of parsing error reporting, other than g_set_printerr_handler
    along with trying to parse whatever output the g_printerr produced.
    I really need a better way to deal with error conditions.

There are some other things that I understand Benjamin is already
working on; I am very much looking forward to his work and will comment
on those later.

regards,
-- 
Björn Höhrmann · mailto:bjoern hoehrmann de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/