JNode 0.2.7 Released
The JNode team is proud to announce the release of JNode 0.2.7.
JNode is a free, open source Java technology based operating system implemented in the Java language with a very small assembler nano-kernel.
This release features the integration of the OpenJDK implementation of Swing and AWT, and significant improvements to the overall JNode GUI including improved painting and font rendering, generic VESA support and graphical console. The release also includes a new command argument framework for the shell, reworked shell commands, a configure tool for the JNode build environment, Samba file system with read/write support and many stability and bug fixes across the whole system.
JNode 0.2.7 is a development release targeting Java developers and computer software specialists who like the idea of a Java based operating system. It is intended to encourage people to join in the creation of this truly unique and innovative free operating system.
We would like to thank all contributors for their efforts in making this release possible.
Screenshots are available here: http://www.jnode.org/node/132
JNode can be downloaded from here: http://www.jnode.org/node/2705
Changelog: http://www.jnode.org/node/2696
More information on the JNode project can be found at http://www.jnode.org and http://sourceforge.net/projects/jnode
:: ~ JNode.free(yourMind); ~ ::
- Login to post comments
say hi!
wow...hello!! i was just studying for an operating system examination and i was wondering if would be a java OS... so i discovered this project (a real consolidated one) and i loved it...
i would love to do some contributions as my knowledge allows but first of all i'd like to try it...so i've a few questions,
i was searching in requirements and it does not mention nothing about Celeron... that is what i have, but i'm planning in a near future to buy a core 2 duo...would it work on that?
well..and others that i don't know yet.
bye!
Font rendering
How would the following character sequence render in JNode 0.2.7 ?
\u0623
\u0647
\u0644
\u0627
\u064B
ً
When output to a text console ...
... the characters all render as "?" characters. This is for both raw PC console and a text console running under the JNode GUI.
Please feel free to help us address this "shortcoming" .
Wrong design ?
See this discussion, which is more than 2 years old.
If i'm not wrong and if this is the code responsible for rendering, I'm afraid this problem is much more than a "shortcoming".
The public final void render(Surface surface, Shape clip, AffineTransform tx, CharSequence str, final int x, final int y, Color color) method shows some potential problems.
1) I'm not sure str has been BIDI-reordered before being passed to the method (the example I have provided is a right to left one)
2) BDFGlyph glyph = bdfFont.getGlyph(str.charAt(i)); apparently shows that there is a 1:1 relationship between characters and glyphs, which is not true for every script (1:N and N:1 relationships are also possible)
3) offset += glyph.getDWidth().width; seems to only take horizontal offsets into account.
The True Type code seems to use the same logic.
It also looks that the glyphs are cached. I'm not sure it makes sense for 1:N relationships.
Well, I'm not sure we can have a clean font rendering with bitmap fonts, but no rendering at all is not a good solution either. You probably would have to rely on OpenJDK font features and, possibly, on Roman Kenke's work (see this entry point).
Not bad design ...
I don't think that the real problem is bad design as such. Rather output of UTF-8 to consoles has simply not been implemented.
Look at the following two methods in org.jnode.driver.console.spi.ConsoleOutputStream. As you can see they don't even try to deal with encoded output such as UTF-8. Instead, they just smash the bytes into chars and throw them at the screen. This code is definitely used for a raw PC consoles, and based on the behavior I guess it is also used for GUI consoles.
Character streams
This (possibly) direct stream access, without prior attempt to decode it (into a CharSequence for instance), is another potential problem indeed.
What I wanted to point out are the assumptions made in the font rendering code, i.e. the 1:1 relationship between character and glyph and the (apparent) lack of normalization/BIDI-reordering.
To provide a simple example :
LATIN SMALL LETTER E WITH ACUTE might be rendered by 2 glyphes ("e" then "´" both sharing the same start offset)
LATIN SMALL LETTER E + COMBINING ACUTE ACCENT might be rendered by 1 glyph ("é" if the font supports it)
Well, I'm still not sure if this is handled by higher-level routines.
The way to be sure ...
... is to write a small test program. That is how I determined what the text consoles would do.