[libcroco-list] Some library user feedback...
- From: Bjoern Hoehrmann <derhoermi gmx net>
- To: libcroco-list gnome org
- Subject: [libcroco-list] Some library user feedback...
- Date: Thu, 18 Jan 2007 15:18:53 +0100
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
* 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
* 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.
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/
] [Thread Prev