To be fair I think the rendering quality can be attributed to the html/css
processing. For instance parsing is completely done by golang.org/x/net/html
and github.com/aymerick/douceur. (Also one can get quite far with handling
display: inline/inline-block/flex and height/width attributes)
One
The figures turn out to be quite practical though! :) Non-utf8 Encoding for
most forms should work now, although some corner-cases for POST are still
missing.
Probably the fonts could be copied over or you can look for fonts that include
subfonts covering the fullwidth ranges 0xff01-0xffe5. By
I wonder if this could be copied from how plan9port behaves on macOS for
instance. Using a single tap and then toggling/chording using alt and command
keys. Maybe on a multi-touch input the distance of the 2nd and 3rd finger could
help to identify which modifier/button it translates to.
Hm ok, that's rather tricky to reproduce. (Also unfortunately I don't have a
running 9legacy system) One thing I noticed though that for instance on
https://ja.wikipedia.org the parentheses are usually fullwidth parentheses and
on 9front rendered to the UTF8 face :-). I added a commit which
That was unexpected, but it should be much better now! Now the character set
hint is actually used
‐‐‐ Original Message ‐‐‐
Am Freitag, 23 April 2021 06:37 schrieb :
> Please look at http://google.co.jp
>
> We see many 'NULL' on this page.
>
> Kenji
>
>
>
> > One big disadvantage is not having 'colspan'...
>
> Nice, now it has this, and do resizing of the window!
True! At least the colspan is gracefully ignored, but probably it's really not
that important :D
Philip
--
9fans: 9fans
Permalink:
Although I guess generally it's good to have more than one Browser available.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-Mfe40f44f07f618e8e041c150
Delivery options:
Awesome, no problem!
> There is still 'NUL' character when 漢字 and ( or ), hankaku moji,
are mixed: like
> 例(日本語) ==>例NUL日本語NUL
I wonder what that could be. So with the current version (910bfe from
yesterday) it can work if the input is UTF-8: http://psilva.sdf.org/ja.html Do
you maybe have a
Hi!
Here's a patch for most of the fullwidth glyphs in lucidasans and vga! The
subfonts are already used in each font file. I guess one way to quickly test
would be:
hget https://ja.wikipedia.org | htmlfmt > /tmp/wp
for (font in /lib/font/bit/lucidasans/unicode.*.font
Awesome!!!
‐‐‐ Original Message ‐‐‐
Am Dienstag, 23. März 2021 14:06 schrieb :
> We are thrilled to announce that Nokia has transferred the copyright of
> Plan 9 to the Plan 9 Foundation. This transfer applies to all of the
> Plan 9 from Bell Labs code, from the earliest days through
About Go 1.16.3, I had initially another problem when compiling. While running
the compiler expected the bootstrapping files to be in a certain path. I think
something like /tmp/glenda/.../..., so I renamed the path and it worked. I
didn't check further though, but I'll check again later.
Vulkan (at least its promises) looks interesting though. As far as I understand
it's more like a Meta API, really low-level and it claims to be very portable.
But as mentioned before, the Hello Worlds are really long, apparently it's
rather >1000 lines instead of "just" >100 for OpenGL.
On the
Not sure if it's wasted/duplicate effort but I had been interested in porting
QuickJS (it has ES 2020 support) Eventually I stopped doing this since there is
Duktape (within Netsurf) and Goja now support some of the most common ES6
features. Also my C knowledge/porting experience is quite
Awesome, I'll try that! Yeah I realize there is also this Bignum support,
that's probably not a very common use case.
On Saturday, September 4th, 2021 at 17:24, Sigrid Solveig Haflínudóttir
wrote:
> https://git.sr.ht/~ft/quickjs
>
> I have not finished it, ofc, but it successfully ran a few
Hi!
Actually there is a separate fork of 9fans.net/go that also runs on Plan 9 and
uses the /dev/draw there! Here it's now all merged together:
https://github.com/psilva261/go
Philip
> How I can use those sam/samterm on plan9?
>
> I compiled those, and run sam as
>
> teerm% sam
>
> samterm:
Hi,
also from me merry Christmas and happy New Year! I think the Plan 9 Bootcamp
from smj which happened also in 2021 is really great. That makes it much easier
to really get started doing interesting things despite 9front already being
surprisingly well documented and easy to install.
I see, now it's actually updated :-)
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T585a46c9a2003432-M7c816af7c0c36e4032e44391
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
An additional link:
http://shithub.us/ph/misc/f54501c2592bd7cee283a243391d07f2dd131373/9legacy/f.html
That's a bit improvised. I might still organize this a bit better or move this
into garden eventually. (Thanks for letting me archive this though)
Philip
‐‐‐ Original Message ‐‐‐
On
Ah ok, I think it should now be self-contained:
http://shithub.us/ph/misc/HEAD/9legacy/f.html
Included also the pi4rc and the bootusb.rc! (Not really sure about the
sam_label_command_riosnarf.diff, probably I'll take a look another time and at
least add something to the README)
Greetings,
Also of course it depends on what needs to be rendered. I didn't deep-dive yet
into the internals of it, but isn't it that when combining the images at the
end, that transfer of the initial images with lots of data basically happens
only once? It seems to me devdraw can be quite performant on
Hosting options are quite limited though, there's Hetzner and actually also Arm
Virtual Hardware but I couldn't get 9front running there. And at least on real
hardware running 32 bit on aarch64 seems to work. Also on macOS qemu there's
hardware acceleration. I've tried that as well but I think
Hi,
I've only tried qemu with 9front and this got me to a console (the files in
dos/ are from the image):
EXTRA_ARGS='user=glenda nobootprompt=local!/dev/sdM0/fs virtio nousbrc='
qemu-system-aarch64 -M raspi3b -dtb dos/bcm2711-rpi-4-b.dtb -kernel dos/9PI3
-append "console='1 b9600'
Hello,
I'm trying to understand how pipes work when terminating a forked process. It
seems when sending kill to the forked process, connected pipes don't always
break. At least a subsequent write might work. Is it possible to make it
reliably fail anyway or is it necessary to close the file
23 matches
Mail list logo
