<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: いろいろ</title>
	<atom:link href="http://www.mblondel.org/journal/2007/07/25/%e3%81%84%e3%82%8d%e3%81%84%e3%82%8d/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mblondel.org/journal/2007/07/25/%e3%81%84%e3%82%8d%e3%81%84%e3%82%8d/</link>
	<description>Machine Learning, Data Mining, Natural Language Processing…</description>
	<lastBuildDate>Mon, 02 Jan 2012 10:53:06 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Peter Maydell</title>
		<link>http://www.mblondel.org/journal/2007/07/25/%e3%81%84%e3%82%8d%e3%81%84%e3%82%8d/#comment-9028</link>
		<dc:creator>Peter Maydell</dc:creator>
		<pubDate>Tue, 14 Aug 2007 13:46:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.mblondel.org/journal/2007/07/25/%e3%81%84%e3%82%8d%e3%81%84%e3%82%8d/#comment-9028</guid>
		<description>My primary hope for Tomoe is that it provides a reasonable way of looking up words in a Japanese-&gt;English dictionary. I can&#039;t offhand think of much use for entering a single character -- after all, almost all Japanese words are two kanji, or a kanji and some kana...

I don&#039;t know if you&#039;ve ever used a Zaurus; the (proprietary, alas) recognition engine there is very good, to the extent that I usually reckoned it was faster to write kanji than to write kana and select the correct kanji, and it&#039;s certainly much better than using a virtual keyboard to enter ASCII characters to convert to kana and then kanji.

I just want a UI for entering kanji into a dictionary application which doesn&#039;t obscure the text field I&#039;m trying to enter the kanji in to, really.</description>
		<content:encoded><![CDATA[<p>My primary hope for Tomoe is that it provides a reasonable way of looking up words in a Japanese-&gt;English dictionary. I can&#8217;t offhand think of much use for entering a single character &#8212; after all, almost all Japanese words are two kanji, or a kanji and some kana&#8230;</p>
<p>I don&#8217;t know if you&#8217;ve ever used a Zaurus; the (proprietary, alas) recognition engine there is very good, to the extent that I usually reckoned it was faster to write kanji than to write kana and select the correct kanji, and it&#8217;s certainly much better than using a virtual keyboard to enter ASCII characters to convert to kana and then kanji.</p>
<p>I just want a UI for entering kanji into a dictionary application which doesn&#8217;t obscure the text field I&#8217;m trying to enter the kanji in to, really.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mathieu</title>
		<link>http://www.mblondel.org/journal/2007/07/25/%e3%81%84%e3%82%8d%e3%81%84%e3%82%8d/#comment-9022</link>
		<dc:creator>Mathieu</dc:creator>
		<pubDate>Tue, 14 Aug 2007 02:42:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.mblondel.org/journal/2007/07/25/%e3%81%84%e3%82%8d%e3%81%84%e3%82%8d/#comment-9022</guid>
		<description>Uraka.Lee &gt; If by smart keyboard, you mean the virtual keyboard, yes it can. :)

Peter &gt; Yes I agree that rewriting something in assembly should always be the last resort. 

About the UI remark... I don&#039;t see handwriting recognition in Maemo as a way to input text or words, at least as for now. Handwriting recognition for Maemo is currently seen as a way to input isolated characters. In this regard, it is mainly intended to Chinese/Japanese learners as a quick way to look up a character, and to a smaller extent to native speakers who can&#039;t recall one given character. 

The reason for that is that Tomoe&#039;s current recognition algorithm is not bad but you have to write strokes very carefully and in the correct order.  There&#039;s no way it can understand cursive style... Thus, I think it wouldn&#039;t be convenient nor fast to input a lot of characters with it.

Personally, I&#039;m skeptical that handwriting recognition can be very convenient for quickly inputing text (both in Chinese/Japanese and in languages that use the latin alphabet). However, it can be useful for elderly people because it can be easier for them. Recognition accuracy should be a lot improved when Tomoe gets an HMM recognition module but this is not for today. HMM for example allows to recognize the whole shape of the character instead of each stroke one by one.

What I would love to have on the N800 is a cellphone-like input method. The virtual keyboard would just have 12 keys (10 + 2) so the keys would be bigger and it would be possible to use thumbs to quickly input text with the touchscreen.</description>
		<content:encoded><![CDATA[<p>Uraka.Lee > If by smart keyboard, you mean the virtual keyboard, yes it can. :)</p>
<p>Peter > Yes I agree that rewriting something in assembly should always be the last resort. </p>
<p>About the UI remark&#8230; I don&#8217;t see handwriting recognition in Maemo as a way to input text or words, at least as for now. Handwriting recognition for Maemo is currently seen as a way to input isolated characters. In this regard, it is mainly intended to Chinese/Japanese learners as a quick way to look up a character, and to a smaller extent to native speakers who can&#8217;t recall one given character. </p>
<p>The reason for that is that Tomoe&#8217;s current recognition algorithm is not bad but you have to write strokes very carefully and in the correct order.  There&#8217;s no way it can understand cursive style&#8230; Thus, I think it wouldn&#8217;t be convenient nor fast to input a lot of characters with it.</p>
<p>Personally, I&#8217;m skeptical that handwriting recognition can be very convenient for quickly inputing text (both in Chinese/Japanese and in languages that use the latin alphabet). However, it can be useful for elderly people because it can be easier for them. Recognition accuracy should be a lot improved when Tomoe gets an HMM recognition module but this is not for today. HMM for example allows to recognize the whole shape of the character instead of each stroke one by one.</p>
<p>What I would love to have on the N800 is a cellphone-like input method. The virtual keyboard would just have 12 keys (10 + 2) so the keys would be bigger and it would be possible to use thumbs to quickly input text with the touchscreen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Maydell</title>
		<link>http://www.mblondel.org/journal/2007/07/25/%e3%81%84%e3%82%8d%e3%81%84%e3%82%8d/#comment-9016</link>
		<dc:creator>Peter Maydell</dc:creator>
		<pubDate>Mon, 13 Aug 2007 23:11:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.mblondel.org/journal/2007/07/25/%e3%81%84%e3%82%8d%e3%81%84%e3%82%8d/#comment-9016</guid>
		<description>Hi. Some remarks on the UI... I think ideally the tomoe handwriting area should appear where the virtual keyboard is and be about the same size; you want as much of the screen usable for the application proper as possible. Random idea: divide this space into four character entry boxes side by side. As the user writes a character in each box and moves on to the next one, the boxes switch to displaying the candidate kanji. The idea is that you can write a word (or most of one) and then confirm the engine&#039;s choices with a few taps of the stylus. The aim is to have the UI keep out of the way as much as possible. You could probably fit some buttons in on the right of the entry boxes for actions like &#039;recognise kana/numbers/whatever&#039; and &#039;back to virtual kbd&#039;.

I wouldn&#039;t bother with the ARM assembly personally -- you&#039;ll almost always get better results from finding a better algorithm instead. I&#039;d also have used separate processes rather than threads (easier to write reliable code) but then I&#039;m an old-school unix kind of guy :-)

Anyway, cool stuff and I look forward to using it.</description>
		<content:encoded><![CDATA[<p>Hi. Some remarks on the UI&#8230; I think ideally the tomoe handwriting area should appear where the virtual keyboard is and be about the same size; you want as much of the screen usable for the application proper as possible. Random idea: divide this space into four character entry boxes side by side. As the user writes a character in each box and moves on to the next one, the boxes switch to displaying the candidate kanji. The idea is that you can write a word (or most of one) and then confirm the engine&#8217;s choices with a few taps of the stylus. The aim is to have the UI keep out of the way as much as possible. You could probably fit some buttons in on the right of the entry boxes for actions like &#8216;recognise kana/numbers/whatever&#8217; and &#8216;back to virtual kbd&#8217;.</p>
<p>I wouldn&#8217;t bother with the ARM assembly personally &#8212; you&#8217;ll almost always get better results from finding a better algorithm instead. I&#8217;d also have used separate processes rather than threads (easier to write reliable code) but then I&#8217;m an old-school unix kind of guy :-)</p>
<p>Anyway, cool stuff and I look forward to using it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Uraka.Lee</title>
		<link>http://www.mblondel.org/journal/2007/07/25/%e3%81%84%e3%82%8d%e3%81%84%e3%82%8d/#comment-8999</link>
		<dc:creator>Uraka.Lee</dc:creator>
		<pubDate>Sun, 12 Aug 2007 11:03:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.mblondel.org/journal/2007/07/25/%e3%81%84%e3%82%8d%e3%81%84%e3%82%8d/#comment-8999</guid>
		<description>Congratulations to you. It seems Tomoe can now cooperate with smart keyboard?</description>
		<content:encoded><![CDATA[<p>Congratulations to you. It seems Tomoe can now cooperate with smart keyboard?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

