Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1526 > unrolled thread

Future Unicode support

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-23 07:22 +0100
    Re: Future Unicode support Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-23 07:07 +0000
      Re: Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-23 14:24 +0100
        Re: Future Unicode support Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-23 20:53 +0000
          Re: Future Unicode support Ron <beeb@woosh.co.nz> - 2012-03-24 12:21 +1300
            Re: Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-24 05:42 +0100
              Re: Future Unicode support Ron <beeb@woosh.co.nz> - 2012-03-24 22:53 +1300
                Re: Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-24 14:12 +0100
              Re: Future Unicode support Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-24 22:11 +0000
                Re: Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-25 12:50 +0200
            Re: Future Unicode support Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-24 22:10 +0000
              Re: Future Unicode support Ron <beeb@woosh.co.nz> - 2012-03-26 03:26 +1300
                Re: Future Unicode support Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-25 16:43 +0100
                Re: Future Unicode support Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-26 00:39 +0200
                  Re: Future Unicode support Ron <beeb@woosh.co.nz> - 2012-03-26 12:18 +1300

#1526 — Future Unicode support

A suggestion for future font/character set support


The more I dig into this situation, the more I'm recalling druck's 
comment about RISC OS being a toy. It's not that the system isn't 
capable, it's that it hasn't been made capable.

Capable of what?

Supporting non-Latin character sets *natively* with any sense of 
being.


First things first, we don't care about VDU text. Seriously, it isn't 
that big a deal - it is no different on Windows, for I have set 
SMPlayer to pass the filenames as eight-dot-three style names. Why? 
Because Chihiro Onitsuka is five squiggles and MPlayer brainfarts 
when asked to play stuff like ?????-???????.flv.


Ideally, we would also make the transition so F12 opens a command 
window, and ^F12 does the task line. Time to look towards staying in 
the multitasking realm and moving away from command lines. Oh, and 
defaulting stuff (Edit, Draw, etc) to using an appropriate font and 
not "System text".


The ironic thing is the logic is in place, not just for a Unicode 
capable OS, but for the level of support to be handled on a 
PER-APPLICATION basis. I fully believe the Wimp is capable of 
handling a task that is Latin1 only and a task that is UTF-8, side by 
side, without problems. Indeed, as the choice is UTF-8 and not the 
Windowsy double-byte system, this means actually a lot of stuff can 
go through without translation. For example:

error%!0 = 1234
$(error%+4)= "Rick is a bit of a dick, isn'the?" + CHR$(0)
...Wimp_ReportError here...

would be the same on both systems. It is only when you get to 
accented characters that you have differences, for instance:

error%!0 = 1234
$(error%+4)= "Can you show me the way to TÅkyÅ?" + CHR$(0)

where things will start to differ. Or "Tôkyô" with macrons replaced 
by little (Latin1 friendly) east asian rain hats, or something.;-)

I believe this requirement should be passed as a Wimp flag (not a 
late Wimp version) so that an application has the opportunity to 
probe for Unicode support (via PlatformFeatures) and perhaps load 
messages files/templates as appropriate from Unicode/OldSchool.

This will, if the flag is accepted by the Wimp,apply across the board 
for that application - all text in Wimp calls, all text in templates, 
everything treated as UTF-8. The setting of *Alphabet should be 
demoted to mean "system default otherwise" (ie, what the Wimp will 
select if an application is NOT UTF-8 capable).

Again, since we're going UTF-8 and not double-byte, we don't need to 
be like Windows with two sets of API calls. The same call can cater 
for both cases.

It'll need a hack of TemplEd, of course.

There is no requirement to revert Unicode back to something else. 
How, for instance, would you stand a hope in hell of changing the 
Chinese or Korean for stuff like "OK", "Cancel", "Search"? It should 
just be presented as strings which the Wimp will display. Correctly. 
;-)

The International module needs to be expanded to:

1. Cater for UCS <-> UTF-8 conversions. For instance, the Japanese 
language is Nihongo. Three kanji. No, you can't cut'n'paste that into 
Notepad! The characters are 26085, 26412, and 35486. In UTF-8, this 
would be: 230, 151, 165, 230, 156, 172, 232, 170, and 158. It is a 
programmatic conversion where, for example, the lead byte indicates 
how many bytes there are, plus part-encoding the character. So a set 
of SWIs could convert a character in, say, R0 to a sequence of bytes 
in the buffer given in R1; and vice versa. For INSTANCE. It would be 
better as an OS function rather than in a C library because, well, 
systems with good C library support don't tend to be capable of 
running BASIC programs. We can, so why not make such facilities 
available? That's what the OS is there for...

2. Convert system character set reference to UTF-8. For example, 'é' 
is 195, 169. This can probably be catered for using a lookup table. 
Going backwards will, of course be slower as it'll need to scan the 
table the other way around, though I can see this used mainly for 
compatibility (like, here's a (Latin1) string, go Unicodeify it).

3. Support the concept of on the fly keyboard/alphabet changes. If 
you've seen my eeePC's keyboard (photo/video on my blog somewhere), 
you'll know that it has little katakana keycaps in addition to the 
standard layout. Without getting into horrible complications with the 
IME, my machine has a little icon where I can select to treat the 
keyboard as a British keyboard, a Japanese keyboard, or a French 
(AZERTY) keyboard. The last one is because when my keyboard broke I 
plugged in a French USB model. I can alter keyboards (and associated 
capabilities) on the fly. So too could RISC OS, ne? I could stick 
kana letters on my RiscPC's keyboard and switch between kana and 
English in a heartbeat. It needs only two additional things - firstly 
a keyboard driver that can spit out kana (better, an IME, but you get 
the point), and secondly a notification service.

Now the notification service is important because I was, frankly, 
appalled that I could *Alphabet in a taskwindow and nothing happened. 
Actually, a lot happened, but the OS didn't bother to let anybody 
know. When either a keyboard OR the alphabet is altered, a service 
call should be issued. This should be picked up by the Wimp that then 
broadcasts a notificational message (a la "ModeChanged" etc). This 
Wimp message is very important, for userland applications should 
*not* be dicking around with ways of intercepting service calls and 
other lower-level stuff. Likewise, Sprow suggests sitting on a 
vector. NO - again, we need to rethink the messages the Wimp can 
broadcast, and hand *IT* the job of informing clients when stuff 
happens. This is to be a new RISC OS where stuff happens in the GUI, 
not in the RMA! Do we have a "CD inserted" message? Or does a CD 
client application need to loop-poll the drive? Remember the role of 
the OS here, it shouldn't be up to the client to say "something there 
yet? something there yet? something there yet?", it should be the 
sworn duty of the client to sleep until the OS tells it "something's 
there".

Next up, the font manager. I was reading part of the spec on the 
Iyonix site. Would I be correct in thinking the font manager can do 
on-the-fly substitutions, so - for instance, if the font is Trinity 
and you want to write "konnichiwa", it can pull in the kana from, 
say, MaruGothic or Cyberbits? If so, that's both cool and useful.

Is MaruGothic available anywhere?

Is the Japanese IME described by Kevin Bracey available anywhere? [I 
know a tiny amount of Japanese, I know *zero* Korean, so a hangul IME 
is no much use to me!]

Aaaaanyway, thoughts and suggestions. It is twenty past seven in the 
morning, the end of my day and I'm dead tired, so please excuse 
typos, illogical bits, and other mistakes.


Best wishes,

Rick.

[toc] | [next] | [standalone]

#1527

In message <almarsoft.3869465234381739290@news.orange.fr>
 on 23 Mar 2012 Rick Murray  wrote:

> Next up, the font manager. I was reading part of the spec on the Iyonix
> site. Would I be correct in thinking the font manager can do on-the-fly
> substitutions, so - for instance, if the font is Trinity and you want to
> write "konnichiwa", it can pull in the kana from, say, MaruGothic or
> Cyberbits? If so, that's both cool and useful.

I don't think it's that clever.  The RUfl library, which is part of
the NetSurf project, can do this however.

There was a long thread on the RISC OS Open Ltd forums a few months ago,
which start off being around how keyboard input could be extended, perhaps to
allow an enhanced !Chars to insert Unicode characters into the stream even
when the alphabet is Latin 1.

I think Ben Avison was of the opinion that we just needed to switch the
alphabet to UTF-8 once things were ready, as most applications would probably
"just work".  The big worry I had with this, which I never got round to
expressing, is how applications are supposed to know how to interpret the
data in files they have saved on disc, files you get from other RISC OS
users, etc.

Clearly, applications still in active development can be rewritten to make
sure they record the character set used in files, if they don't already, but
for other applications, in my view, it is ESSENTIAL that there be some way to
allow them to continue to operate in a Latin 1 (or Latin 2 etc.) environment,
and specifying the work required so we can put bounties against the
components, like for the filing system improvements, would be very
worthwhile.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1528

On Fri, 23 Mar 2012 07:07:24 GMT, Matthew Phillips 
<spam2011m@yahoo.co.uk> wrote:

> which start off being around how keyboard input could be extended,

My personal feeling is that there ought to be another word in the 
poll block which describes the character in a Unicode sense *in 
addition* to the existing one. Thus, if a user enters e-acute, they 
get it the Latin1 way (old style) and Unicode. If it is o-macron, 
they get '?' and Unicode. This should allow the least possible 
breakage. Old unaware software might see a lot of '???' but they 
possibly wouldn't work well anyway (case in point, how well can you 
cut'n'paste kanji under XP? It only works for apps that support it, 
else it is question mark city...).
Remember also the Wimp has attached special meaning to some codes 
>256 (cursors, etc).


> is how applications are supposed to know how to interpret the data
> in files they have saved on disc, files you get from other RISC OS 
users, etc.

You don't. This was part of the reason for the two calls to 
make/unmake this string Unicode. It ought to be *assumed* that the 
majority of files will be Latin1, so files in Unicode will need to 
explicity state that they are, in fact, so. This is the simple 
solution.

The longer solution is that UTF-8 is actually fairly self detecting. 
Not just the marker sequence (that most places seem to suggest you 
*don't* use), but also all sequences use high-bit-set characters, 
they specify a length, so it should be possible to scan a string and 
see if it "makes sense as Unicode". This might be a better solution, 
but it is more work and thus would take longer...


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1531

In message <almarsoft.6419659065395120605@news.orange.fr>
 on 23 Mar 2012 Rick Murray  wrote:

> On Fri, 23 Mar 2012 07:07:24 GMT, Matthew Phillips 
> <spam2011m@yahoo.co.uk> wrote:
> 
> > which start off being around how keyboard input could be extended,
> 
> My personal feeling is that there ought to be another word in the 
> poll block which describes the character in a Unicode sense *in 
> addition* to the existing one.

This was very similar to the view I was promoting on the thread on the forum.

> Remember also the Wimp has attached special meaning to some codes 
> 256 (cursors, etc).

I suspect that if it hadn't, no-one would ever have thought of passing UTF-8
characters through Key_pressed events as individual bytes!

> > is how applications are supposed to know how to interpret the data in
> > files they have saved on disc, files you get from other RISC OS 
> > users, etc.
> 
> You don't. This was part of the reason for the two calls to 
> make/unmake this string Unicode. It ought to be *assumed* that the 
> majority of files will be Latin1, so files in Unicode will need to 
> explicity state that they are, in fact, so. This is the simple 
> solution.

I agree.  The difficulty comes if an old application which is still being
used (e.g. via Aemulor) starts being run under an environment where the
alphabet is now UTF-8.

Ben Avison, in the thread I mentioned, was against having transitional
arrangements of the sort you were suggesting.  He was pointing out that text
in Wimp user messages (many of which are not understood by the Wimp itself)
might have to be converted to/from UTF-8 according to whether the application
was running Latin-1 compatibility mode or not.  He was therefore advocating
complete switch-over to UTF-8 at some date in the future, rather than
long-term support for two modes of operation.

See http://www.riscosopen.org/forum/forums/3/topics/700?page=2#posts-8231

What I never got round to contributing to that thread was the following
worry:

Suppose a popular application, still used by many users, such as Impression,
continues to be used after the bit switch-over to UTF-8.  Impression knows
nothing (I assume) about the character sets in use.  It's just rendering all
its stuff in the default alphabet.  Any user starting from scratch with
Impression and creating new files might well be OK.  But there's no way
Impression could convert old files to display correctly in the new
environment without being rewritten, and frankly, to start with after the
switch to UTF-8 the user is more likely to have old files than new ones. 
Besides, the user will continue to receive Impression files from other RISC
OS users who have not made the switch.

Obviously Impression is just an example (and if it is character set aware,
then I apologise to the fore-sighted folk at Computer Concepts).  Almost any
application which saves text to disc would be affected.

In the thread I cited I was proposing a modest improvement to !Chars which
could be ignored by applications, but which would allow arbitrary Unicode
characters to be fed to applications without the whole machine having to
affected by an alphabet switch.  We have a chicken and egg situation.  Many
applications have not been rewritten to be aware of character sets, but there
is little incentive for the developer to do this when the user cannot really
take advantage and input exotic characters.  But if the user switches
alphabets then data saved by unaware applications will be interpreted oddly,
so the users don't want to switch either.  The change to !Chars would not
help input Japanese or anything really complex, but it would make it possible
for compliant applications to allow users to use the occasional unusual
character (e.g. Polish accents, snippets of Greek) when they need to.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1532

In message <22fa217552.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
          <snip>
> The change to !Chars would not help input Japanese or anything really
> complex, but it would make it possible for compliant applications to
> allow users to use the occasional unusual character (e.g. Polish accents,
>  snippets of Greek) when they need to.
> 
How difficult would it be to upgrade the bitfont system?
8x16 is very poor and effects StrongEd as well as the system apps.

In Zap and apps that use ZapFonts I can use a higher resolution
Bitmap and the difference with those extra points is fantastic.

If the default font was increased in size to 12x24 or bigger,
I think that would improve the Desktop quality.

Bitmaps seem to perform better (no flicker for one thing) and
wouldn't be quicker for printing out custom fonts if they a bitmap
already?

Plan9 has a 2byte font system but they use a bitmap for Nihongo,
also for the purpose of printing.

Nowadays, storage space is not the problem, but Arm's are still
lacking in performance generally, so any way to remove un-needed
calculations should be taken.

I think one good Latin Bitmap font should be all that you'd need
in the ROM.
The current Outline fonts don't meet technical requirements and
could be packaged for themes and as an extra for applications.

I guess you still need the unicode system to describe the extra
characters regardless, so I'm a little off topic here.

Ron M.   

[toc] | [prev] | [next] | [standalone]

#1533

On Sat, 24 Mar 2012 12:21:53 +1300, Ron <beeb@woosh.co.nz> missed the 
point completely...

> How difficult would it be to upgrade the bitfont system?

Depends on dependencies - namely how many bits of the operating 
system make assumptions based upon known aspects of the system font. 
Plus, anything that actually depends upon system font and/or 
redefines characters will instantly break if you go and change stuff 
like that.


> If the default font was increased in size to 12x24 or bigger,
> I think that would improve the Desktop quality.

<cough> What? What would improve desktop quality is to get rid of the 
damned system font!

You know, I was running a compile in a taskwindow on an emulated 
version of RISC OS and mom walked by. I shall quote exactly: Wow, 
that's old-fashioned looking.
I didn't have the heart to say it was RISC OS's chunky system text so 
I told her I was playing with some retro stuff. Like she'd know the 
difference, she isn't literate beyond Yahoo mail and looking up stuff 
on Google! But you gotta admit, VDU text with chunky edges is just so 
eighties. Hell, why stop there? Let's colour it in gaudy shades of 
blue and orange and yellow. [older people may remember Arthur's 
quirky palette]


> wouldn't be quicker for printing out custom fonts if they a bitmap
> already?

Bitmaps are good . . . for dumping on to a specific screen resolution 
at a specific size. FAIL at other resolutions. FAIL at other sizes. 
FAIL at printing (any how any way). 


> but Arm's are still lacking in performance generally,

Your benchmark being what? ARM is good enough for Apple (iPhone, 
iPod, iPad), good enough for Amazon (Kindle), good enough for the 
majority of Android phones (like the one I'm writing this on). Sure, 
it won't match the grunt of a quad-core 3GHz x86 box, but that isn't 
where ARM excels. It can, certainly, provide a feature rich good 
looking rendered and hinted antialiased display. Just look at... 
well... pretty much any useful Android phone. I'm writing this on an 
Xperia Mini Pro. Do you think I'm looking at bitmap text? You're 
joking, right? There's no bitmap text once you get beyond the 
bootloader.


> so any way to remove un-needed calculations should be taken.

You're in danger of becoming a troll. If you want to remove 
unnecessary calculations, please write in assembler. Seriously, have 
you seen the output of the C compiler?

Quote:
   TST v3, #2
   BEQ |L00098c.J11.draw_icon|
   MOV v4, #0
   B |L000990.J13.draw_icon|
|L00098c.J11.draw_icon|
   MOV v4, #7
|L000990.J13.draw_icon|
   Etc...

Having seen that, I recoded the function in hand-crafted assembler 
and translated the above mess into:
   TST  R7, #2
   MOVNE R10, #0
   MOVEQ R10, #7
   Etc...

So if you're really serious about every nanosecond counts, C is out. 
Goes without saying an INTERPRETED language is a dead duck. No more 
BASIC either.


Or you can accept that there's enough power in the ARM that miniscule 
delays in pondering outline fonts is far outweighed by their 
benefits.


> I think one good Latin Bitmap font should be all that you'd need
> in the ROM.

I think you've pretty much missed the point. A song I quite like is 
帰り路をなくして by 鬼束ちひろ. If you can't see any of that, or a bunch of 
question marks, it pretty much makes the point. There's a world 
beyond western European languages. Are we interested?

Note, again, in case it wasn't ENTIRELY clear, I am writing this on 
an Android phone, it looks good, it copes with "squiggles"...
...and it runs an ARM.

Want to see? Look at http://www.heyrick.co.uk/random/androidtext.png 
for a screenshot of how the above two paragraphs look on my phone. My 
ARM powered phone. :-P 


> The current Outline fonts don't meet technical requirements

Explain?

There are some deficiencies due to the format being designed with 
older limitations in mind, but it is adapting fairly well actually. 
On the other side of the fence, we have TrueType and OpenType side by 
side (but then TrueType sucked from day one...).


Just as a totally throw-away nerr-nerr, I have a short video in 720p 
H.264 (that's basic HD). My 1.6GHz eeePC901 can't cope with it, even 
passing stuff over to the (admittedly lame) Intel GPU.
My 1GHz ARM mobile phone doesn't even break a sweat, and happily 
overlays subtitles, does background mail fetches, etc. Okay, it 
probably gets a DSP to do the grunt work, but then so too should a 
Windows codec involve the graphics chipset, that ain't the early '90s 
no more!

Though, I will accept that watching HD video on a three inch 480x320 
display is probably something of an exercise in futility. :-)


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1534

In message <almarsoft.996210831280217351@news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On Sat, 24 Mar 2012 12:21:53 +1300, Ron <beeb@woosh.co.nz> missed the 
> point completely...
> 
> > How difficult would it be to upgrade the bitfont system?
> 
> Depends on dependencies - namely how many bits of the operating 
> system make assumptions based upon known aspects of the system font. 
> Plus, anything that actually depends upon system font and/or 
> redefines characters will instantly break if you go and change stuff 
> like that.
> 
> 
> > If the default font was increased in size to 12x24 or bigger,
> > I think that would improve the Desktop quality.
> 
> <cough> What? What would improve desktop quality is to get rid of the 
> damned system font!

Yes but past years of useage has shown that outline fonts are Ok in
the display type apps like Messenger and Netsurf but for interactive
editors the Bitmap font redraws better. It's either put up with the
Bitmap font or put up with the editting flicker with outline fonts.
> 
> > wouldn't be quicker for printing out custom fonts if they a bitmap
> > already?
> 
> Bitmaps are good . . . for dumping on to a specific screen resolution 
> at a specific size. FAIL at other resolutions. FAIL at other sizes. 
> FAIL at printing (any how any way). 
> 
Yes I know the arguments for scalable fonts, but at some stage in every
output there is a conversion to dots wether it is a printer or a
display. Obviously Postcript at least allows this conversion to be
done on the printer most of the times.

The trouble with Postscript and PDF's and other supposed standards,
They get terribly messed about with different creaters and on
RISC OS they can be a pain and unrealistic to read. There is a 
large percentage that would display 20 times faster as a bit
image which is a ridiculous situation, considering the original
concept of Postscript. 
I'm not blaming RISC OS apps in particular, but bitmaps can 
solve a lot of issues we face.
  
> > but Arm's are still lacking in performance generally,
> 
> Your benchmark being what? ARM is good enough for Apple (iPhone, 
> iPod, iPad), good enough for Amazon (Kindle), good enough for the 
> majority of Android phones (like the one I'm writing this on). Sure, 
> it won't match the grunt of a quad-core 3GHz x86 box, but that isn't 
> where ARM excels. It can, certainly, provide a feature rich good 
> looking rendered and hinted antialiased display. Just look at... 
> well... pretty much any useful Android phone. I'm writing this on an 
> Xperia Mini Pro. Do you think I'm looking at bitmap text? You're 
> joking, right? There's no bitmap text once you get beyond the 
> bootloader.
> 
Maybe your'e right, The Iyonix is not all that short of the mark.

> > so any way to remove un-needed calculations should be taken.
> 
> You're in danger of becoming a troll. If you want to remove 
> unnecessary calculations, please write in assembler. Seriously, have 
> you seen the output of the C compiler?
> 
That doesn't sound good :-( 
If you can make improvements like the below alludes to, I think that
I would put my money where my mouth is and pay for those type of
improvements rather than a new machine.


> Quote:
>    TST v3, #2
>    BEQ |L00098c.J11.draw_icon|
>    MOV v4, #0
>    B |L000990.J13.draw_icon|
> |L00098c.J11.draw_icon|
>    MOV v4, #7
> |L000990.J13.draw_icon|
>    Etc...
> 
> Having seen that, I recoded the function in hand-crafted assembler 
> and translated the above mess into:
>    TST  R7, #2
>    MOVNE R10, #0
>    MOVEQ R10, #7
>    Etc...
> 
> So if you're really serious about every nanosecond counts, C is out. 
> Goes without saying an INTERPRETED language is a dead duck. No more 
> BASIC either.
> 
> 
> Or you can accept that there's enough power in the ARM that miniscule 
> delays in pondering outline fonts is far outweighed by their 
> benefits.
> 
> 
> > I think one good Latin Bitmap font should be all that you'd need
> > in the ROM.
> 
> I think you've pretty much missed the point. A song I quite like is 
> 帰り路をなくして by 鬼束ちひろ. If you can't see any of that, or a bunch of 
> question marks, it pretty much makes the point. There's a world 
> beyond western European languages. Are we interested?
>

Yes we know (RISC OS users), it's a bit like telling us that we wont see
that javascript, or flash or HTML emails. I was expecting to have
Unicode when I bought the Iyonix, Definetly it would be nice to
have, I didn't make comment here to put you off, I'm just pointing out
with my current system I need bitmap fonts, and if only there was a
way to improve them. I did mention that I was off your main topic. 
  
<snip>
> > The current Outline fonts don't meet technical requirements
> 
> Explain?
> 
A font that is clear to read and no two characters look the same.
ie.  l and 1 or |  0 and O  and so on. The outline font I am using
does not display the up arrow in the switcher icon menu. 
All these things can be edited very easily with a bitmap font.
It is also possible to edit outline fonts of course, but I was
questioning why we have (any) fonts that need editting stuck hard in
the ROM. They might as well be in a package.

> There are some deficiencies due to the format being designed with 
> older limitations in mind, but it is adapting fairly well actually. 
> On the other side of the fence, we have TrueType and OpenType side by 
> side (but then TrueType sucked from day one...).
> 
> 
> Just as a totally throw-away nerr-nerr, I have a short video in 720p 
> H.264 (that's basic HD). My 1.6GHz eeePC901 can't cope with it, even 
> passing stuff over to the (admittedly lame) Intel GPU.
> My 1GHz ARM mobile phone doesn't even break a sweat, and happily 
> overlays subtitles, does background mail fetches, etc. Okay, it 
> probably gets a DSP to do the grunt work, but then so too should a 
> Windows codec involve the graphics chipset, that ain't the early '90s 
> no more!
> 
> Though, I will accept that watching HD video on a three inch 480x320 
> display is probably something of an exercise in futility. :-)
>
 
A refreshing trend coming from these portables, they must be using 
clever programming instead of the blunt instrument approach of bigger
storage, faster hardware.
I'm making not bad progress with porting utilities at the moment.
I now have troff, which can convert unix man pages to text.

cheers, Ron M. 

 

[toc] | [prev] | [next] | [standalone]

#1535

On Sat, 24 Mar 2012 22:53:09 +1300, Ron <beeb@woosh.co.nz> wrote:

> the display type apps like Messenger and Netsurf but for interactive
> editors the Bitmap font redraws better. It's either put up with the
> Bitmap font or put up with the editting flicker with outline fonts.

I've never really noticed flicker when writing a *lot* in OvationPro 
on a 40MHz machine. Maybe it is your editor...?


> but at some stage in every output there is a conversion to dots
> wether it is a printer or a display.

Obviously, as both screens and printers are dot-based. However you 
can scale up and down and zoom in without a loss of quality...


[PDFs]
> They get terribly messed about with different creaters and on
> RISC OS they can be a pain and unrealistic to read.

Ditto PCs. On my site is a "fixed" PDF of the ADLC (econet) 
datasheet, 'cos the original didn't work on Adobe Reader. This is not 
the fault of the display technology or the file format in principle. 
It is the fault of either the creator or the reader, depending on 
what is actually broken...


> There is a large percentage that would display 20 times faster
> as a bit image which is a ridiculous situation,

Not at all. Bit images don't need to be thought about, they just need 
to be splatted on to the screen. Fonts, diagrams, those things need 
to be scaled and *drawn*.

Under RISC OS, given the userbase is often using older slower 
hardware so it is a trade off between memory use and redraw speed.


> but bitmaps can solve a lot of issues we face.

Not at all. I have a document of a circuit diagram. As a PDF it works 
on my PC, my phone, and I would imagine RISC OS too.

As a bitmap? Would you like it 96dpi for the screen? How would that 
look on a printer? Or maybe 600dpi for a printer. You can't render 
that to screen by dropping pixels, as it might mean you lose sight of 
circuit traces, so you'd be best off error diffusing it to screen 
res.

And suddenly, you're doing almost as much work as drawing a PDF, only 
instead of working with a few 100Ks of descriptions, you'll be wading 
through many megabytes of image data...


> If you can make improvements like the below alludes to,

The compiler is generally fairly good, but there are some things that 
generate rather naff code. Can't speak for the latest compiler, but 
the slightly older one does jump tables by jumping to an instruction 
that then branches. You could load the branch address directly and 
save one branch...

Whether or not it is viable to do this, I don't know. But before we 
complain too much, due to the retarded nature of x86, various C 
compilers output appalling-looking code; I'm not skilled in x86 so 
don't know if the compiler sucks or if that's just what you need to 
do... 


> A font that is clear to read and no two characters look the same.

Change font! ;-)


> The outline font I am using does not display the up arrow in the
> switcher icon menu. 

Fonts are not supposed to contain stuff like that. You ought to have 
a font called WimpSymbol that makes this stuff available...


> It is also possible to edit outline fonts of course, but I was
> questioning why we have (any) fonts that need editting stuck hard in
> the ROM.

One of the nice things about RISC OS is that you can bring up a 
functional system with... nothing.

Okay, we need !Boot for all the new things, but the most basic setup 
will start directly from ROM and give a working system with no 
harddisc or anything.


> A refreshing trend coming from these portables, they must be using 
> clever programming instead of the blunt instrument approach of 
bigger
> storage, faster hardware.

Nah, that's the x86 approach.

Two cores not good enough? Try four!


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1536

In message <almarsoft.996210831280217351@news.orange.fr>
 on 24 Mar 2012 Rick Murray  wrote:

> Seriously, have you seen the output of the C compiler?
> 
> Quote:
>    TST v3, #2
>    BEQ |L00098c.J11.draw_icon|
>    MOV v4, #0
>    B |L000990.J13.draw_icon|
> |L00098c.J11.draw_icon|
>    MOV v4, #7
> |L000990.J13.draw_icon|
>    Etc...
> 
> Having seen that, I recoded the function in hand-crafted assembler 
> and translated the above mess into:
>    TST  R7, #2
>    MOVNE R10, #0
>    MOVEQ R10, #7
>    Etc...

Which C compiler?  GCC or Norcroft?  Which version.  It doesn't seem very
ARM-aware!

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1538

On Sat, 24 Mar 2012 22:11:58 GMT, Matthew Phillips 
<spam2011m@yahoo.co.uk> wrote:

> Which C compiler?  GCC or Norcroft?  Which version.  It doesn't 
seem very
> ARM-aware!

Norcroft from Castle days. Can't remember the version offhand.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1537

In message <d2962f7552.beeb@ron1954.woosh.co.nz>
 on 23 Mar 2012 Ron  wrote:

> How difficult would it be to upgrade the bitfont system? 8x16 is very poor
> and effects StrongEd as well as the system apps.
> 
> In Zap and apps that use ZapFonts I can use a higher resolution Bitmap and
> the difference with those extra points is fantastic.
> 
> If the default font was increased in size to 12x24 or bigger, I think that
> would improve the Desktop quality.

That would reduce your screen capacity by 56%, if you look at the area
occupied by the same number of characters in each bitmap fonts size.  I can't
spare that.

> Bitmaps seem to perform better (no flicker for one thing) and
> wouldn't be quicker for printing out custom fonts if they a bitmap
> already?

Flicker is largely a matter of how well-written the application is.  If the
application tells the Wimp to redraw the whole line when only a small part
has changed, you get flicker.  It's nothing to do with the speed of the
processor.  Many applications are happy to let the Wimp clear the window
background to white and then overprint, but it is possible to do both in the
one operation, just more fiddly to program.

Are you talking about printing to paper?  You cannot seriously be suggesting
using bitmap fonts for printing, can you?  RISC OS screen resolution is
nominally 90 dpi.  For decent printing, to avoid seeing jagged edges, you
need at least 300 dpi, preferably more.

> Nowadays, storage space is not the problem, but Arm's are still lacking in
> performance generally, so any way to remove un-needed calculations should
> be taken.

The ARM2 was good enough to do anti-aliased font rendering at an acceptable
speed more than twenty years ago.

> The current Outline fonts don't meet technical requirements and could be
> packaged for themes and as an extra for applications.

The outline font system is about the only bit which does meet technical
requirements: no problem with Unicode there.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1539

In message <f6daac7552.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> 
> Are you talking about printing to paper?  You cannot seriously be suggesting
> using bitmap fonts for printing, can you?  RISC OS screen resolution is
> nominally 90 dpi.  For decent printing, to avoid seeing jagged edges, you
> need at least 300 dpi, preferably more.
> 
That is what was suggested, I dont know how exactly yet. (Nihongo)
If Postscript is not doing it, you would have to send a decent resolution,
the same as printing any bitmap image.
Bitmap fonts aren't upward scalable, so you'd need at least the large set.

The 8x16 font was with us when we had low resolution monitors, and it
hasn't been changed to reflect double the size monitors.
The Zapfont I use is 10x20 and a big improvement in shape, clarity and
importantly individuality, which is where I fault the Rom supplied
outline fonts. That is why I question wether anything other than a
full descriptive (for the system) font should be in the rom.
 
I dont have anything against outline fonts, the current situation I
have is, that the display is worse than a BBC when typing even a 
single character. (30 years on and I have a jittery editor)

Ron M. 

[toc] | [prev] | [next] | [standalone]

#1540

In message <e643067652.beeb@ron1954.woosh.co.nz>
 on 25 Mar 2012 Ron  wrote:

> I dont have anything against outline fonts, the current situation I have
> is, that the display is worse than a BBC when typing even a single
> character.

It really is an implementation problem in the application.  It is possible to
get rid of flicker if the application is written correctly.  I have made
quite a few improvements to redraw in Impact where the code had taken the
lazy option of re-rendering the whole window content -- there's still scope
for improvement!

Perhaps you'd better name the editor!

And in the bitmap versus outline debate, remember that the system has a font
cache, which stores the outline font characters as bitmaps to allow faster
font rendering.  Background font blending onto varying-colour backgrounds
rather does away with any speed improvement, but with older applications this
is unlikely to have been turned on, unless it is forced by using SpecialFX.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1541

On Mon, 26 Mar 2012 03:26:43 +1300, Ron <beeb@woosh.co.nz> wrote:

> have is, that the display is worse than a BBC when typing even a 
> single character. (30 years on and I have a jittery editor)

Two questions:

1. What's the editor that is so horrid?

2. Go to the command line, enter *Status and tell me what your 
FontSize (near the top of the list) and FontMax (six of them near the 
end of the list) say.
Note: If the display appears to freeze, press Shift for the rest.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1542

In message <almarsoft.3635701023849391083@news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On Mon, 26 Mar 2012 03:26:43 +1300, Ron <beeb@woosh.co.nz> wrote:
> 
> > have is, that the display is worse than a BBC when typing even a 
> > single character. (30 years on and I have a jittery editor)
> 
> Two questions:
> 
> 1. What's the editor that is so horrid?
>
It effects all 3, Edit StrongED and Zap.
 
> 2. Go to the command line, enter *Status and tell me what your 
> FontSize (near the top of the list) and FontMax (six of them near the 
> end of the list) say.

FontMax1   16 points
FontMax2   36 points
FontMax3   36 points
FontMax4   16 points
FontMax5   0 points
FontMax    4096k

I notice in !Edit it doesnt happen if using one character for the whole line.

Ron M. 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web