I'm well aware of the limitations/capabilities of opentype and uniscribe (I
followed the VOLT community forum while it lasted) and I know that this is not
an easy subject, if it was it would have already been implemented in iText.
Reinventing the wheel is something that we do everyday, either because of
licence issues or because the available wheels don't fit too well to our
requirements. The problem is that iText is not a Java only library and for the
moment the only thing that is not supported in C# is Graphics2D. Basing
everything in the Java layout capabilities closes the door to other
implementations. Before worrying about the layout itself maybe we should worry
about encapsulating it in a sort of plug-in or well defined classes that could
be replaced according to the language capabilities, layoutGlyphs() in Java and
Uniscribe in C#, for example.
Paulo
> -----Original Message-----
> From: Robert Muir [mailto:[email protected]]
> Sent: Wednesday, April 08, 2009 3:00 PM
> To: Post all your questions about iText here
> Subject: Re: [iText-questions] question about glyph positioning
>
> Paulo, I think I might disagree with your statement. I am not
> sure you want to carry the burden of this implementation...
> seems to be quite a large wheel to reinvent, it is not as
> simple as just additional tables in the font.
>
> without getting into details, I'll just provide short snippet from
> http://en.wikipedia.org/wiki/OpenType
>
> Another difference is that an OpenType support framework
> (such as Microsoft's Uniscribe
> <http://en.wikipedia.org/wiki/Uniscribe> ) needs to provide a
> fair bit of knowledge about special language processing
> issues to handle (for example: Arabic). With AAT, the font
> developer of an AAT font has to encapsulate all that
> expertise in the font. This means that AAT can handle any
> arbitrary language, but that it requires more work and
> expertise from the font developers. On the other hand,
> OpenType fonts are easier to make, but can only support
> complex scripts <http://en.wikipedia.org/wiki/Complex_script>
> if the application or operating system knows how to handle them.
>
>
>
>
> On Wed, Apr 8, 2009 at 9:29 AM, Paulo Soares
> <[email protected]> wrote:
>
>
> Don't get too carried away, the iTextSharp port will
> still have to work and there's no layoutGlyphs() there. I'm
> also a bit worried about the behavior of different java
> versions when layoutGlyphs() is all that is used for
> rendering ligatures. The correct way would be to use the GSUB
> and other tables in the font and solve all the script
> problems that way, including the Indic scripts.
>
> Paulo
>
>
> > -----Original Message-----
> > From: Robert Muir [mailto:[email protected]]
> > Sent: Wednesday, April 08, 2009 2:08 PM
> > To: itext-questions
> > Subject: [iText-questions] question about glyph positioning
> >
> > Hello,
> >
> > I sent a simple patch to get things moving with complex
> > scripts (indic languages) but to get it really correct
> > (example: Urdu language in Nastaliq script), some more things
> > to be done.
> >
> > I've done most of the following to get this language going
> > but its not ready yet:
> >
> > 1. Removal of ArabicLigaturizer/etc code. Instead, Arabic
> > text is passed as-is to layoutGlyphs() which does this
> > transparently. In some cases Arabic fonts do not have
> > presentation forms and do this with opentype GSUB tables
> > (http://partners.adobe.com/public/developer/opentype/index_tab
> > le_formats1.html). Nastaliq fonts are a perfect example of
> > this, as they have thousands of ligatures.
> >
> > 2. text does not need to be reordered by Bidi-Analysis prior
> > to being laid out, however, the argument (RTL, LTR) for a run
> > of text does need to be supplied to layoutGlyphs() to get the
> > correct behavior. So Bidi Analysis is moved.
> >
> > 3. Remaining problem: need to take the vertical positional
> > information from layoutGlyphs(), (derived from GPOS tables:
> > http://partners.adobe.com/public/developer/opentype/index_tabl
> > e_formats2.html) and put this in the PDF somehow. The figure
> > referenced there
> > (http://partners.adobe.com/public/developer/en/images/fig4b.gi
> > f) shows what is currently displayed in PDFS for nastaliq
> > font, "Incorrect".
> >
> > In problem #3 I need to apply some vertical position to an
> > individual glyph... I'm looking at using
> > PDFContentByte.setTextRise() which appears to be designed for
> > subscript/superscript... is there a better way?
> >
> > --
> > Robert Muir
> > [email protected]
Aviso Legal:
Esta mensagem é destinada exclusivamente ao destinatário. Pode conter
informação confidencial ou legalmente protegida. A incorrecta transmissão desta
mensagem não significa a perca de confidencialidade. Se esta mensagem for
recebida por engano, por favor envie-a de volta para o remetente e apague-a do
seu sistema de imediato. É proibido a qualquer pessoa que não o destinatário de
usar, revelar ou distribuir qualquer parte desta mensagem.
Disclaimer:
This message is destined exclusively to the intended receiver. It may contain
confidential or legally protected information. The incorrect transmission of
this message does not mean the loss of its confidentiality. If this message is
received by mistake, please send it back to the sender and delete it from your
system immediately. It is forbidden to any person who is not the intended
receiver to use, distribute or copy any part of this message.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
iText-questions mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.1t3xt.com/docs/book.php
