#16 Other charsets.

[Michał Zaborowski]

Hi all,
and thakns for great job!
Can you add more charsets? Also it would be nice to
have two different char sets - source and destination.
Secound one can be same as defined right now.
Why? Ok, at the beggining there was only ISO-8859-2.
After that one big company from Redmond decided to make
their "standard" and - yes! it is different from ISO ;)
Since
my code is done under their system I need encoder,
switcher.
I can do something like that for Polish... Also I can
prepare base for any language.

[Michalis Kamburelis]

Logged In: YES
user_id=987895

Since some time there are two versions of Polish output,
windows-1250 and iso-8859-2. So I think that one part of
this request is fixed.

As for the second thing, as i understand it would require
implementing in pasdoc converter between various charsets.
Sure, it's nothing difficult if it concerns only two
charsets (windows-1250 <-> iso-8859-2), but making a
complere converter for various charsets is definitely out of
scope of pasdoc. Sure, we could use iconv library, but this
would also be an incomplete solution, since users will
immediately wish for ability to do other text convertion,
not only involving character sets convertions.

I see two sensible solutions:

1. Make an option for pasdoc to filter unit files contents
   (before they are parsed by pasdoc) by some external program.
   Then user can use iconv program (or any other, like e.g. a C
   preprocessor, since some people use a C preprocessor with
   their Pascal code). E.g.
   pasdoc --filter-unit='iconv -f WINDOWS-1250 -t ISO-8859-2' ...

Pasdoc passes original unit's contents as stdin for filter
program, and reads it's stdout. Implementing it nicely
shouldn't even involve any need for creating some temporary
file, since stdin and stdout may be provided from/to a memory.

Option --filter-unit should be allowed to be specified
multiple times, and pasdoc should call filter programs in
the same order as their --filter-unit options were specified.

But I say that we should implement it only if it's really
easy. Why ? Because user has already an ability to do such
thing manually by creating some script that
- copies his unit to some temporary directory,
- processes them with iconv, or some other program,
- runs pasdoc over them

Sure, using pasdoc's --filter-unit option would be easier,
but that's all.

1. Second proposition (harder to do) would be to allow to
   specify some kind of plugins (e.g.
   --filter-plugin=pasdoc-iconv-plugin.so) and pasdoc would use
   them to process only unit's descriptions (not whole units
   sources). Advantage over 1. would be that only descriptions
   are passed to such plugin, not whole unit's sources. That's
   also why plugin (i.e., shared library) must be used instead
   of external program, since executing external program for
   each description would be definitely too slow.

These are my thoughs. My vote is for 1., because it's
easier, or for rejecting this request, because, as I
explained above, it's already possible, the only drawback is
that user must write some script.