mobile translation systme study
Post on 06-Apr-2018
227 Views
Preview:
TRANSCRIPT
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 1/25
ANDROID
Android is a software stack for mobile devices that includes an operating system,
middleware and key applications. The Android SDK provides the tools and APIs necessary to
begin developing applications on the Android platform using the Java programming language.
Features
y Application framework enabling reuse and replacement of components
y Dalvik virtual machine optimized for mobile devices
y Integrated browser based on the open source WebKit engine
y Optimized graphics powered by a custom 2D graphics library; 3D graphics
based on the OpenGL ES 1.0 specification (hardware acceleration optional)
y SQLite for structured data storage
y Media support for common audio, video, and still image formats (MPEG4,
H.264, MP3, AAC, AMR, JPG, PNG, GIF)
y GSM Telephony (hardware dependent)
y Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
y Camera, GPS, compass, and accelerometer (hardware dependent)
y Rich development environment including a device emulator, tools for debugging,memory and performance profiling, and a plugin for the Eclipse IDE
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 2/25
Android Architecture
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 3/25
Applications
Android will ship with a set of core applications including an email client, SMS program,
calendar, maps, browser, contacts, and others. All applications are written using the Java
programming language.
Application Fundamentals
y Android applications are composed of one or more application components (activities,
services, content providers, and broadcast receivers)y Each component performs a different role in the overall application behavior, and each
one can be activated individually (even by other applications)
y The manifest file must declare all components in the application and should also declare
all application requirements, such as the minimum version of Android required and any
hardware configurations required
y Non-code application resources (images, strings, layout files, etc.) should include
alternatives for different device configurations (such as different strings for different
languages and different layouts for different screen sizes)
Android applications are written in the Java programming language. The Android SDK toolscompile the code²along with any data and resource files²into an Android package, an archive
file with an .apk suffix. All the code in a single .apk file is considered to be one application and
is the file that Android-powered devices use to install the application.
Once installed on a device, each Android application lives in its own security sandbox:
y The Android operating system is a multi-user Linux system in which each application is a
different user.
y By default, the system assigns each application a unique Linux user ID (the ID is used
only by the system and is unknown to the application). The system sets permissions for all the files in an application so that only the user ID assigned to that application can
access them.
y Each process has its own virtual machine (VM), so an application's code runs in isolation
from other applications.
y By default, every application runs in its own Linux process. Android starts the process
when any of the application's components need to be executed, then shuts down the
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 4/25
process when it's no longer needed or when the system must recover memory for other
applications.
In this way, the Android system implements the principle of least privilege. That is, each
application, by default, has access only to the components that it requires to do its work and no
more. This creates a very secure environment in which an application cannot access parts of the
system for which it is not given permission.
However, there are ways for an application to share data with other applications and for an
application to access system services:
y It's possible to arrange for two applications to share the same Linux user ID, in which
case they are able to access each other's files. To conserve system resources, applicationswith the same user ID can also arrange to run in the same Linux process and share the
same VM (the applications must also be signed with the same certificate).
y An application can request permission to access device data such as the user's contacts,
SMS messages, the mountable storage (SD card), camera, Bluetooth, and more. All
application permissions must be granted by the user at install time.
That covers the basics regarding how an Android application exists within the system. The rest
of this document introduces you to:
y The core framework components that define your application.
y The manifest file in which you declare components and required device features for your
application.
y Resources that are separate from the application code and allow your application to
gracefully optimize its behavior for a variety of device configurations.
Application Components
Application components are the essential building blocks of an Android application. Each
component is a different point through which the system can enter your application. Not all
components are actual entry points for the user and some depend on each other, but each one
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 5/25
exists as its own entity and plays a specific role²each one is a unique building block that helps
define your application's overall behavior.
There are four different types of application components. Each type serves a distinct
purpose and has a distinct lifecycle that defines how the component is created and destroyed.
Here are the four types of application components:
Activities
An activity represents a single screen with a user interface. For example,
an email application might have one activity that shows a list of new emails,
another activity to compose an email, and another activity for reading emails.
Although the activities work together to form a cohesive user experience in the
email application, each one is independent of the others. As such, a different
application can start any one of these activities (if the email application allows it).
For example, a camera application can start the activity in the email application
that composes new mail, in order for the user to share a picture.
An activity is implemented as a subclass of Activity and you can learn
more about it in the Activities developer guide.
Services
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 6/25
A service is a component that runs in the background to perform long-
running operations or to perform work for remote processes. A service does not
provide a user interface. For example, a service might play music in the
background while the user is in a different application, or it might fetch data over
the network without blocking user interaction with an activity. Another
component, such as an activity, can start the service and let it run or bind to it in
order to interact with it. A service is implemented as a subclass of Service and
you can learn more about it in the Services developer guide.
Content providers
A content provider manages a shared set of application data. You can store the
data in the file system, an SQLite database, on the web, or any other persistent storage
location your application can access. Through the content provider, other applications
can query or even modify the data (if the content provider allows it). For example, the
Android system provides a content provider that manages the user's contact
information. As such, any application with the proper permissions can query part of
the content provider (such asContactsContract.Data) to read and write information
about a particular person.
Content providers are also useful for reading and writing data that is private to
your application and not shared. For example, the Note Pad sample application uses a
content provider to save notes.
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 7/25
A content provider is implemented as a subclass of ContentProvider and must
implement a standard set of APIs that enable other applications to perform
transactions. For more information, see the Content Providers developer guide.
Broadcast receivers
A broadcast receiver is a component that responds to system-wide broadcast
announcements. Many broadcasts originate from the system²for example, a
broadcast announcing that the screen has turned off, the battery is low, or a picture
was captured. Applications can also initiate broadcasts²for example, to let other
applications know that some data has been downloaded to the device and is available
for them to use. Although broadcast receivers don't display a user interface, they
may create a status bar notification to alert the user when a broadcast event occurs.
More commonly, though, a broadcast receiver is just a "gateway" to other
components and is intended to do a very minimal amount of work. For instance, it
might initiate a service to perform some work based on the event.
A broadcast receiver is implemented as a subclass of BroadcastReceiver and
each broadcast is delivered as an Intent object. For more information, see the
BroadcastReceiver class.
A unique aspect of the Android system design is that any application can start
another application¶s component. For example, if you want the user to capture a
photo with the device camera, there's probably another application that does that and
your application can use it, instead of developing an activity to capture a photo
yourself. You don't need to incorporate or even link to the code from the camera
application. Instead, you can simply start the activity in the camera application that
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 8/25
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 9/25
makes it easy to update various characteristics of your application without modifying code and²
by providing sets of alternative resources²enables you to optimize your application for a variety
of device configurations (such as different languages and screen sizes).
MOBILE TRANSILATION
Mobile translation is a machine translation service for hand-held
devices, including mobile telephones, Pocket PCs, and PDAs. It relies on computer
programming in the sphere of computational linguistics and the device's communication means
(Internet connection or SMS) to work. Mobile translation provides hand-held device users with
the advantage of instantaneous and non-mediated translation from one human language to
another, usually against a service fee that is, nevertheless, significantly smaller than a human
translator charges. Mobile translation is part of the new range of services offered to mobile
communication users, including location positioning (GPS service), e-wallet (mobile banking),
business card/bar-code/text scanning etc.
Optical character recognition, usually abbreviated to OCR , is
the mechanical or electronic translation of scanned images of handwritten, typewritten or printed
text into machine-encoded text. It is widely used to convert books and documents into electronic
files, to computerize a record-keeping system in an office, or to publish the text on a website.
OCR makes it possible to edit the text, search for a word or phrase, store it more compactly,
display or print a copy free of scanning artifacts, and apply techniques such as machine
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 10/25
translation, text-to-speech and text mining to it. OCR is a field of research in pattern
recognition, artificial intelligence and computer vision.
OCR systems require calibration to read a specific font; early versions needed to be
programmed with images of each character, and worked on one font at a time. "Intelligent"
systems with a high degree of recognition accuracy for most fonts are now common. Some
systems are capable of reproducing formatted output that closely approximates the original
scanned page including images, columns and other non-textual components. In 1929 Gustav
Tauschek obtained a patent on OCR in Germany, followed by Paul W. Handel who obtained
a US patent on OCR in USA in 1933.
OCR is an instance of off-line character recognition, where the system recognizes the
fixed static shape of the character, while on-line character recognition instead recognizes
the dynamic motion during handwriting. For example, on-line recognition, such as that used for
gestures in the Penpoint OS or the Tablet PC can tell whether a horizontal mark was drawn right-
to-left, or left-to-right. On-line character recognition is also referred to by other terms such as
dynamic character recognition, real-time character recognition, and Intelligent Character
Recognition or ICR.
Features
Mobile translation may include a number of useful features, auxiliary to text translation
which forms the basis of the service. While the user can input text using the device keyboard,
they can also use pre-existing text in the form of email or SMS messages received on the user's
device (email/SMS translation). It is also possible to send a translated message, optionally
containing the source text as well as the translation.
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 11/25
Some mobile translation applications also offer additional services that further facilitate the
translated communication process, such as:
speech generation (speech synthesis), where the (translated) text may be transformed into
human speech (by a computer that renders the voice of a native speaker of the target
language);
Speech recognition, where the user may talk to the device which will record the speech and
send it to the translation server to convert into text before translating it;
mage translation, where the user can take a picture (using the device camera) of some printed
text (a road sign, a restaurant menu, a page of a book etc.), have the application send it to the
translation server which will apply Optical Character Recognition (OCR) technology, extract
the text, return it to the user for editing (if necessary) and then translate it into the chosen
language.
voice interpreting, where the user can select the required language combination and then get
connected automatically to a live interpreter. Currently applications available for iPhone
include iLinguaPro developed by companies
Advantages
Having portable real-time automated translation at one's disposal has a number of practical uses
and advantages.
Travelling: Real time mobile translation can help people travelling to a foreign country to
make themselves understood or understand others.
Business networking: Conducting discussions with (potential) foreign customers using
mobile translation saves time and finances, and is instantaneous. Real time mobile translation
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 12/25
is a much lower cost alternative to multilingual call centres using human translators.
Networking within multinational teams may also be greatly facilitated using the service.
Globalization of Social Networking: Mobile translation allows chatting and text messaging
with friends at an international level. New friends and associates could be made by
overcoming the language barrier.
Learning a foreign language: Learning a foreign language can be made easier and less
expensive using a mobile device equipped with real time machine translation. Statistics
reveal that most college students own mobile phones and find that learning a foreign
language via mobile phone proves to be cheaper than on a PC. Furthermore, the portability
of mobile phones makes it convenient for the foreign language learners to study outside the
classroom in any place and in their own time.
Challenges and disadvantages
Advances of mobile technology and of the machine translation services have helped reduce or
even eliminate some of the disadvantages of mobile translation such as the reduced screen size of
the mobile device and the one-finger keyboarding. Many new hand-held devices come equipped
with a QWERTY keyboard and/or a touch-sensitive screen, as well as handwriting recognition
which significantly increases typing speed. After 2006, most
new mobile phones and devices began featuring large screens with greater resolutions of 640 x
480 px, 854 x 480 px, or even 1024 x 480 px[11]
, which gives the user enough visible space to
read/write large texts.
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 13/25
However, the most important challenge facing the mobile translation industry is the
linguistic and communicative quality of the translations. Although some providers claim to have
achieved an accuracy as high as 95%, boasting proprietary technology that is capable of
³understanding´ idioms and slang language, machine translation is still distinctly of lower
quality than human translation and should be used with care if the matters translated require
correctness.
A disadvantage that needs mentioning is the requirement for a stable Internet connection
on the user's mobile device. Since the SMS method of communicating with the translation server
has proved less efficient that sending packets of data ± because of the message length limit (160
characters) and the higher cost of SMS as compared with Internet traffic charges ± Internet
connectivity on mobile devices is a must, while coverage in some non-urban areas is still
unstable.
Research interest in Latin-based OCR faded away more than a decade ago, in favor of
Chinese, Japanese, and Korean (CJK) followed more recently by Arabic , and then Hindi.These
languages provide greater challenges specifically to classifiers, and also to the other components
of OCR systems.Chinese and Japanese share the Han script, which contains thousands of
different character shapes. Korean uses the Hangul script, which has several thousand more of its
own, as well as using Han characters. The number of characters is one or two orders of
magnitude greater than Latin. Arabic is mostly written with connected characters, and its
characters change shape according to the position in a word. Hindi combines a small number of
alphabetic letters into thousands of shapes that represent syllables. As the letters combine, they
form ligatures whose shape only vaguely resembles the original letters. Hindi then combines the
problems of CJK and Arabic, by joining all the symbols in a word with a line called the shiro-
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 14/25
reka. Research approaches have used language-specific work-arounds to avoid the problems in
some way, since that is simpler than trying to find a solution that works for all languages. For
instance,the large character sets of Han, Hangul, and Hindi are mostly made up of a much
smaller number of components, known as radicals in Han, Jamo in Hangul, and letters in Hindi.
Since it is much easier to develop a classifier for a small number of classes, one approach has
been to recognize the radicals and infer the actual characters from the combination of radicals.
This approach is easier for Hangul than for Han or Hindi, since the radicals don't change shape
much in Hangul characters, whereas in Han, the radicals often are squashed to fit in the character
and mostly touch other radicals. Hindi takes this a step further by changing the shape of the
consonants when they form a conjunct consonant ligature. Another example of a more language-
specific work-around for Arabic, where it is difficult to determine the character boundaries to
segment connected components into characters. A commonly used method is to classify
individual vertical pixel strips, each of which is a partial character, and combine the
classifications with a Hidden Markov Model that models the character boundaries.
Google is committed to making its services available in as many languages as possible
[7], so we are also interested in adapting the Tesseract Open Source OCR Engine to many
languages.This paper discusses our efforts so far in fully internationalizing Tesseract, and the
surprising ease with which some of it has been possible. Our approach is use language generic
methods, to minimize the manual effort to cover many languages.
Review Of Tesseract For Latin
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 15/25
The new page layout analysis for Tesseract was designed from the beginning to be
language-independent, but the rest of the engine was developed for English, without a great deal
of thought as to how it might work for other languages. After noting that the commercial engines
at the time were strictly for black-on-white text, one of the original design goals of Tesseract was
that it should recognize white-on-black (inverse video) text as easily as black-on-white. This led
the design (fortuitously as it turned out) in the direction of connected component (CC) analysis
and operating on outlines of the components. The first step after CC analysis is to find the blob s
in a text region. A blob is a putative classifiable unit, which may be one or more horizontally
overlapping CCs, and their inner nested outlines or holes. A problem is detecting inverse text
inside a box vs. the holes inside a character. For English, there are very few characters (maybe ©
and ®) that have more than 2 levels of outline, and it is very rare to have more than 2 holes, so
any blob that breaks these rules is "clearly" a box containing inverse characters, or even the
inside or outside of a frame around black-on-white characters.After deciding which outlines
make up blobs, the text line finder detects (horizontal only) text lines by virtue of the vertical
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 16/25
overlap of adjacent characters on a text line. For English the overlap and baseline are so well
behaved that they can be used to detect skew very precisely to a very large angle. After finding
the text lines, a fixed-pitch detector checks for fixed pitch character layout, and runs one of two
different word segmentation algorithms according to the fixed pitch decision. The bulk of the
recognition process operates on each word independently, followed by a final fuzzy-space
resolution phase, in which uncertain spaces are decided. In most cases, a blob corresponds to a
character, so the word recognizer first classifies each blob, and presents the results to a
dictionary search to find a word in the combinations of classifier choices for each blob in the
word. If the word result is not good enough, the next step is to chop poorly recognized
characters, where this improves the classifier confidence. After the chopping possibilities are
exhausted, a best-first search of the resulting segmentation graph puts back together chopped
character fragments, or parts of characters that were broken into multiple CCs in the original
image. At each step in the best-first search, any new blob combinations are classified, and the
classifier results are given to the dictionary again. The output for a word is the character string
that had the best overall distance-based rating, after weighting according to whether the word
was in a dictionary and/or had the best overall distance-based rating, after weighting according to
whether the word was in a dictionary and/or had a sensible arrangement of punctuation around it.
For the English version, most of these punctuation rules were hard-coded.
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 17/25
The words in an image are processed twice. On the first pass, successful words, being
those that are in a dictionary and are not dangerously ambiguous, are passed to an adaptive
classifier for training. As soon as the adaptive classifier has sufficient samples,it can provide
classification results, even on the first pass. On the second pass, words that were not good
enough on pass 1 are processed for a second time, in case the adaptive classifier has gained more
information since the first pass over the word.From the foregoing description, there are clearly
problems with this design for non-Latin languages, and some of the more complex issues will be
dealt with in sections 3, 4 and 5, but some of the problems were simply complex engineering.
For instance,the one byte code for the character class was inadequate, but should it be replaced
by a UTF-8 string, or by a wider integer code? At first we adapted Tesseract for the Latin
languages, and changed the character code to a UTF-8 string, as that was the most flexible, but
that turned out to yield problems with the dictionary representation (see section 5), so we ended
up using an index into a table of UTF-8 strings as the internal class code.
3. Layout Preprocessing
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 18/25
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 19/25
text-line finding by sub-dividing text regions into blocks of uniform text size and line spacing.
This makes it possible to force-fit a line-spacing model, so the text-line finding has been
modified to take advantage of this. The page layout analysis also estimates the residual skew of
the text regions, which means the text-line finder no longer has to be insensitive to skew. The
modified text-line finding algorithm works independently for each text region from layout
analysis, and begins by searching the neighborhood of small CCs (relative to the estimated text
size) to find the nearest body-text-sized CC. If there is no nearby bodytext- sized CC, then a
small CC is regarded as likely noise, and discarded. (An exception has to be made for
dotted/dashed leaders, as typically found in a table of contents.) Otherwise, a bounding box that
contains both the small CC and its larger neighbor is constructed and used in place of the
bounding box of the small CC in the following projection.
A "horizontal" projection profile is constructed, parallel to the estimated skewed
horizontal, from the bounding boxes of the CCs using the modified boxes for small CCs. A
dynamic programming algorithm then chooses the best set of segmentation points in the
projection profile. The cost function is the sum of profile entries at the cut points plus a measure
of the variance of the spacing between them. For most text, the sum of profile entries is zero,
and the variance helps to choose the most regular line-spacing.For more complex situations, the
variance and the modified bounding boxes for small CCs combine to help direct the line cuts to
maximize the number of diacriticals that stay with their appropriate body characters.
Once the cut lines have been determined, whole connected components are placed in the text-line
that they vertically overlap the most, (still using the modified boxes) except where a component
strongly overlaps multiple lines. Such CCs are presumed to be either characters from multiple
lines that touch, and so need cutting at the cut line, or drop-caps, in which case they are placed in
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 20/25
the top overlapped line. This algorithm works well, even for Arabic. After text lines are
extracted, the blobs on a line are organized into recognition units. For Latin languages, the
logical recognition units correspond to space-delimited words, which is naturally suited for a
dictionary-based language model. For languages that are not space-delimited, such as Chinese, it
is less clear what the corresponding recognition unit should be. One possibility is to treat each
Chinese symbol as a recognition unit. However, given that Chinese symbols are composed of
multiple glyphs (radicals), it would be difficult to get the correct character segmentation without
the help of recognition. Considering the limited amount of information that is available at this
early stage of processing, the solution is to break up the blob sequence at punctuations, which
can be detected quite reliably based on their size and spacing to the next blob. Although this does
not completely resolve the issue of a very long blob sequence, which is a crucial factor in
determining the efficiency and quality when searching the segmentation graph, this would at
least reduce the lengths of recognition units into more manageable sizes,
Detection of white-on-black text is based on the nesting complexity of outlines. This
same process also rejects non-text, including halftone noise, black regions on the side, or large
container boxes as in sidebar or reversed-video region. Part of the filtering is based on a measure
of the topological complexity of the blobs, estimated based on the number of interior
components, layers of nested holes, perimeter to area ratio, and so on. However, the complexity
of Traditional Chinese characters, by any measure, often exceeds that of an English word
enclosed in a box. The solution is to apply a different complexity threshold for different
languages, and rely on subsequent analysis to recover any incorrectly rejected blobs.
3.3 Estimating x-height in Cyrillic Text
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 21/25
After completing the text line finding step and organizing blocks of blobs into rows,
Tesseract estimates x-height for each text line. The x-height estimation algorithm first
determines the bounds on the maximum and minimum acceptable x-height based on the initial
line size computed for the block. Then, for each line separately, the heights of the bounding
boxes of the blobs occurring on the line are quantized and aggregated into a histogram. From this
histogram the x-height finding algorithm looks for the two most commonly occurring height
modes that are far enough apart to be the potential x-height and ascender height. In order to
achieve robustness against the presence of some noise, the algorithm ensures that the height
modes picked to be the xheight and ascender height have sufficient number or occurrences
relative to the total number of blobs on the line.
This algorithm works quite well for most Latin fonts. However, when applied as-is to
Cyrillic, Tesseract fails to find the correct xheight for most of the lines. As a result, on a data set
of Russian books the word error-rate of Tesseract turns out to be 97%. The reason for such high
error rate is two-fold. First of all the ascender statistics in Cyrillic fonts differ significantly from
Latin ones. Simply lowering the threshold for the expected number of ascenders per line is not an
effective solution, since it is not infrequent that a line of text would contain one or no ascender
letters. The second reason for such poor performance is a high degree of case ambiguity in
Cyrillic fonts. For example, out of 33 upper-case modern Russian letters only 6 have a lower-
case shape that is significantly different from the upper-case in most fonts. Thus, when working
with Cyrillic, Tesseract can be easily misled by the incorrect x-height information and would
readily recognize lower-case letters as upper-case.
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 22/25
Our approach to fixing the x-height problem for Cyrillic was to adjust the minimum
expected number of ascenders on the line, take into account the descender statistics and use x-
height information from the neighboring lines in the same block of text more effectively (a block
is a text region identified by the page layout analysis that has a consistent size of text blobs and
linespacing, and therefore is likely to contain letters of the same or similar font sizes).
For a given block of text, the improved x-height finding algorithm first tries to find the x-
height of each line individually. Based on the result of this computation each line falls into one
of the following four categories:
(1) the lines where the x-height and ascender modes were found, (2) where descenders
were found, (3) where a common blob height that could be used as an estimate of either cap
height or x-height was found, (4) the lines where none of the above were identified (i.e. most
likely lines containing noise with blobs that are too small, too large or just inconsistent in size).
If any lines from the first category with reliable x-height and ascender height estimates were
found in the block, their height estimates are used for the lines in the second category
(lines with descenders present) that have a similar x-height estimate. The same x-height estimate
is utilized for those lines in the third category (no ascenders or descenders found), whose most
common height is within a small margin of the x-height estimate. If the line-by-line approach
does not result in finding any reliable x-height and ascender height modes, the statistics for all
the blobs in the text block are aggregated and the same search for x-height and ascender height
modes is repeated using this cumulative information.
4. Character / Word Recognition
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 23/25
One of the main challenges to overcome in adapting Tesseract for multilingual OCR is
extending what is primarily designed for alphabetical languages to handle ideographical
languages like Chinese and Japanese. These languages are characterized by having a large set of
symbols and lacking clear word boundaries, which pose serious tests for a search strategy and
classification engine designed for well delimited words from small alphabets. We will discuss
classification of large set of ideographs in the next section, and describe the modifications
required to address the search issue first.
4.1 Segmentation and Search
As mentioned in section 3.2, for non-space delimited languages like Chinese, recognition units
that form the equivalence of words in western languages now correspond to punctuation
delimited phrases. Two problems need to be considered to deal with these phrases: they involve
deeper search than typical words in Latin and they do not correspond to entries in the dictionary.
Tesseract uses a best-first-search strategy over the segmentation graph, which grows
exponentially with the length of the blob sequence. While this approach worked on shorter Latin
words with fewer segmentation points and a termination condition when the result is found in the
dictionary, it often exhausts available resources when classifying a Chinese phrase. To resolve
this issue, we need to dramatically reduce the number of segmentation points evaluated
in the permutation and devise a termination condition that is easier to meet.
In order to reduce the number of segmentation points, we incorporate the constraint of
roughly constant character widths in a mono-spaced language like Chinese and Japanese. In
these languages, characters mostly have similar aspect ratios, and are either full-pitch or half
pitch in their positioning. Although the normalized width distribution would vary across fonts,
and the spacing would shift due to line justification and inclusion of digits or Latin words, which
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 24/25
is not uncommon, by and large these constraints provide a strong guideline for whether a
particular segmentation point is compatible with another. Therefore, using the deviation from the
segmentation model as a cost, we can eliminate a lot of implausible segmentation states and
effectively reduce the search space. We also use this estimate to prune the search space based on
the best partial solution, making it effectively a beam search. This also provides a termination
condition when no further expansion is likely to produce a better solution.
Another powerful constraint is the consistency of character script within a phrase. As we
include shape classes from multiple scripts, confusion errors between characters across different
scripts become inevitable. Although we can establish the dominant script or language for the
page, we must allow for Latin characters as well, since the occurrence of English words inside
foreign language books is so common. Under the assumption that characters within a recognition
unit would have the same script, we would promote a character interpretation if it improves the
overall script consistency of the whole unit. However, blindly promoting script characters based
on prior could actually hurt the performance if the word or phrase is truly mixed script. So we
apply the constraint only if over half the characters in the top interpretation belong to the same
script, and the adjustment is weighted against the shape recognition score, like any other
permutation.
.
Requirement Analysis
y Hardware Specification:
8/3/2019 Mobile Translation Systme Study
http://slidepdf.com/reader/full/mobile-translation-systme-study 25/25
1. Android Devices 2.2 version plus
2. SD Card
y Software Specification:
1. Android SDK/ Java technologies
2. IDE( Integrated Development Environment ) Eclipse
top related