On Tue, 8 Jul 2003, Bill Janssen wrote:
> So there is no "support for 0xA5" in the code (and nothing to remove);
This is true for 0xA5. But it's not true for 0xAD. Support for the
soft-hyphen is hardcoded in.
Alex
--
Dr. Alexander R. Pruss || e-mail: [EMAIL PROTECTED]
Philosophy Department
> I propose that we make the soft hyphen character into a function rather
> than an actual character, and remove support for 0xA5 as a soft
> hyphen. Or am I misunderstanding something in the code?
The current code mainly just tries to pass bytes along, so that it
will work for various character
On Tue, 8 Jul 2003, Michael Nordstrom wrote:
> On Tue, Jul 08, 2003, Alexander R. Pruss wrote:
> > Nevermind. I have a horrible memory for numbers--I misremembered the
> > 0x00AD as a 0x00A5.
>
> I think we should "mind" anyway. Bug report #356 is a related problem
> for 0xAD and the Thai langu
On Tue, Jul 08, 2003, Alexander R. Pruss wrote:
> Nevermind. I have a horrible memory for numbers--I misremembered the
> 0x00AD as a 0x00A5.
I think we should "mind" anyway. Bug report #356 is a related problem
for 0xAD and the Thai language.
/Mike
Nevermind. I have a horrible memory for numbers--I misremembered the
0x00AD as a 0x00A5.
While on the subject of soft hyphens, no FntWordWrap() does not handle
them. However, it doesn't really matter given how I use FntWordWrap().
(I back up from the break indicated by FntWordWrap() one char
The Plucker soft hyphen character 0xA5 maps to a yen character on the Palm
side. Does this mean that Plucker can't handle documents with a yen
character?
I propose that we make the soft hyphen character into a function rather
than an actual character, and remove support for 0xA5 as a soft
hyphen.