layoutfarm / typography Goto Github PK

I'm trying Typography with Xamarin.Android but run into the issue: a System.NotSupported exception was thrown when executing reader.BaseStream.Seek(this.Header.Offset, SeekOrigin.Begin).

I'm asking about it in gitter of Xamarin.Android, but I think it may also related to Typography itself. But it work well in .NET core. 😕

I extend this from #24.

reference:

1. http://unicode.org/reports/tr9/

2. http://userguide.icu-project.org/transforms/bidi

3. https://www.microsoft.com/middleeast/msdn/Control.aspx

4. http://stackoverflow.com/questions/8429825/unicode-bidi-text-algorithm-in-c

5. https://en.wikipedia.org/wiki/Arabic_alphabet

6. http://userguide.icu-project.org/transforms/bidi

7. http://www.iamcal.com/understanding-bidirectional-text/

8. http://site.icu-project.org/

9. https://r12a.github.io/

10. https://www.hebrewsyntax.org/bbh2/bbh2_supplement.pdf

11. http://www.unicode.org/Public/PROGRAMS/BidiReferenceJava/

12. https://github.com/prepare/SheenBidi and https://github.com/prepare/SheenFigure

13. http://arabicquick.com/learn_arabic_alphabet/

14. https://gist.github.com/prepare/2d2c81192bbda6a391a76b353d6772e9

15. https://www.w3.org/International/articles/inline-bidi-markup/uba-basics

16. https://www.w3.org/TR/alreq/

17. https://www.w3.org/International/questions/qa-html-dir

In the demo TextBoxSample.WinForms, the rendered text seems to be covered by something white.

For example,

class MyTextPrinter : DevTextPrinterBase { ... }
//...
MyTextPrinter printer = new MyTextPrinter();
printer.FontFilename= "D:\msjh.ttf";
printer.FontSizeInPoints = 12;
printer.DrawString(new []{'A', 'B', 'C', '啊'}, 0, 0);

How to get the actual line height of the layouted and printed text? Is it just printer.FontSizeInPoints?
(I know the function of GlyphLayout is quite limited and can only layout text characters in one line.)

Hi,

I have an issue on the demo. On my environment the GdiPlus demo is drawing characters at wrong positions. Though not familiar with the library, I tried to dig a little bit, and it seems that the DoGlyphPosition methods do nothing. The positions are not updated at all and remain at (0, 0).

I am using VS2017 and upgraded solution, but the build is successful (with a lot of warnings). Not sure whether this is the reason.

Thanks in advance.

I desperately need a text-layout engine written in raw C#. DirectWrite is windows-only. And pango is almost impossible to be compiled on mobile platforms. ( I'm exhausted with cross-compiling, makefiles and defines. It has taken me almost two month to learn and try to achieve that but completely get nothing. )

Will Typography become the C# version DirectWrite or pango? I was searching for papers and algorithms for creating a text-layout engine myself before I ran into this project. It really amazed me when I saw Glyph Layout in ReadMe.

I'm really looking forward to your reply! @prepare

First I'm not a native English speaking person.
so you can correct it where it is wrong grammar/ wrong intention or not proper.

You CAN HELP ME create the topics that you want to know.
so I will create a description for it

:)

ScriptLang plays an important role on Glyph Shaping

for example, Thai Script is a 'complex' script (need GSUB, GPOS)

pic 1: Thai glyphs with incorrect ScriptLang (in red box, latin), shows abnormal result

pic 2: Thai glyphs with correct ScriptLang (in red box, Thai), shows NORMAL result

Now, How about your 'Script' ?, Dose Typography present the text correct or not?

:)

For the moment, NotImplementedException is thrown about whenever an unknown table format is encountered. For instance GPOS.cs has 12 such occurrences, GSUB.cs has 7, and GDEF.cs has 1. But all these three tables are optional in the standard. My understanding is that a client should just ignore the features it does not know about instead of throwing.

How would you feel about replacing those throws with safe fallbacks instead? I can try to do the work but I wanted your thoughts about it first.

(Context: I’m currently writing my own parser for a subset of OpenType for Emoji.Wpf and I thought it might be interesting to use Typography.OpenFont instead, and contribute some of my code.)

implement composite glyph that has more than 1 component

For example, for character 'D', the glyph index for msjh.ttf and Helvetica.ttf are both 39. But for unifont-9.0.06.ttf, the glyph index is 71.

The only way to get a Glyph I found is Typeface.GetGlyphByIndex(). I want to know whether we can get the glyph from the character D directly?

I visit here every day.
I will answer your questions.

But I can't commit about 2-3 weeks.

:)

https://www.microsoft.com/typography/otspec/svg.htm

https://github.com/Microsoft/OpenType-SVG-Font-Editor

https://github.com/twitter/twemoji

If I set canvasPainter.FillColor = new Color(255, 0, 0); in VcxTextPrinter.cs I would expect that the text is rendered in red, but instead it is rendered in blue (using the PixelFarmSample.WinForms sample).

Swapping R and B in ColorOrder.cs results in the correct color being used, but I don’t know where the actual bug is.

As a result, the code in CPAL.cs is incorrect with regards to RGB ordering. The buffer is in BGRA format and the GetColor code should be as follows:

b = colorBGRABuffer[startAt];
g = colorBGRABuffer[startAt + 1];
r = colorBGRABuffer[startAt + 2];
a = colorBGRABuffer[startAt + 3];

Advance typography is in the plan :)

see advanced GSUB/ GPOS at #18

1. Woff

ref https://www.w3.org/TR/WOFF/
some impl => https://github.com/manne/Woff.net

2. Woff2

ref https://www.w3.org/TR/WOFF2/

some impl=> https://github.com/google/woff2

There is a C# port of brotli, see google/brotli#494
and google/brotli#519

https://fontvau.lt/

@prepare's note:

• Woff see=> a0083bf

• Woff2 => ok aadfbaa

From this, we can see each GlyphRun uses a drawcall and it harms performance badly when rendering a string containing many characters.

I think we should apply the offset when we fill the vertex buffer. I mean, bake the offset into vertex instead of offset every glyph in vertex shader, just like what I have done before in my original OpenGLES demo.

Update:
No, my soultion is incorrect partially. The mesh should only be moved after it is built. Otherwise we can not re-use the old mesh when the position of text is changed but its content and style remains the same. But I think the offset of each glyph should be applied to built vertices.

@prepare's note:

• add VBO version for GLES glyph rendering

When I'm testing a ttf file with Typography, Typography.OpenFont.IO.ByteOrderSwappingBinaryReader.ReadInt16 throw an System.IO.EndOfStreamException: 'Unable to read beyond the end of the stream.'

Stack:

Typography.OpenFont.IO.ByteOrderSwappingBinaryReader.ReadInt16() Line 59	C#
Typography.OpenFont.Tables.GPOS.ValueRecord.ReadFrom(System.IO.BinaryReader reader, ushort valueFormat) Line 107	C#
Typography.OpenFont.Tables.GPOS.ValueRecord.CreateFrom(System.IO.BinaryReader reader, ushort valueFormat) Line 158	C#
Typography.OpenFont.Tables.GPOS.PairSetTable.ReadFrom(System.IO.BinaryReader reader, ushort v1format, ushort v2format) Line 49	C#
Typography.OpenFont.Tables.GPOS.LookupTable.ReadLookupType2(System.IO.BinaryReader reader) Line 468	C#
Typography.OpenFont.Tables.GPOS.LookupTable.ReadRecordContent(System.IO.BinaryReader reader) Line 245	C#
Typography.OpenFont.Tables.GPOS.ReadLookupListTable(System.IO.BinaryReader reader, long lookupListBeginAt) Line 170	C#
Typography.OpenFont.Tables.GPOS.ReadContentFrom(System.IO.BinaryReader reader) Line 69	C#
Typography.OpenFont.Tables.TableEntry.LoadDataFrom(System.IO.BinaryReader reader) Line 22	C#
Typography.OpenFont.OpenFontReader.ReadTableIfExists<Typography.OpenFont.Tables.GPOS>(Typography.OpenFont.Tables.TableEntryCollection tables, System.IO.BinaryReader reader, Typography.OpenFont.Tables.GPOS resultTable) Line 162	C#
Typography.OpenFont.OpenFontReader.Read(System.IO.Stream stream, Typography.OpenFont.ReadFlags readFlags) Line 91	C#

The ttf font file I'm using:
DroidSans.zip. I forgot where it is from. But it can be opened by the Windows Font Viewer so it should be valid.

CvtTable cvtTable = ReadTableIfExists(tables, input, new CvtTable());

typeface.ControlValues = cvtTable.controlValues;

The returned cvtTable can be null and that causes a NRE on the next line.

Tested with unifont-9.0.06.ttf from http://unifoundry.com/unifont.html.

from #19

see

1. OpenType spec Math Table

2. XITS - OpenType implementation of STIX fonts with math support

3. Asana

4. https://github.com/mathjax/MathJax

5. https://www.w3.org/TR/MathML3/

6. https://tex.stackexchange.com/questions/2692/comparing-mathjax-and-mathml?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

7. https://developer.mozilla.org/en-US/docs/Web/MathML

8. https://github.com/Happypig375/AMSFonts-Ttf-Otf

9. https://katex.org/

Thank you for this good openSource font reader

see https://www.microsoft.com/typography/otspec/cff2.htm

http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/font/pdfs/5176.CFF.pdf

problem: The old idea, not correct!

zoom in

Thank you @vidstige
I forked this from your https://github.com/vidstige/NRasterizer.
because I don't want to make your github 'network' graph look mess, while I am modifying it.

my goals:

1. use the OpenType Reader to read .ttf
2. render it with the PixelFarm. (we have anti-alias quality software/hardware renderer)

I visit here every day.
I will answer your questions.

But I can't commit about 2-3 weeks.

:)

To notify you, for the C# Font lib developers.

@vidstige
@MikePopoloski
@tocsoft
@Robmaister
@larsbrubaker
@zwcloud

@aaronbell,

Honestly to say. I just found it today :)

https://github.com/Microsoft/Font-Validator

It is the great one from Microsoft with MIT license.

@vidstige , please comment about this how-to-build-each-table

OpenType Layout
(https://www.microsoft.com/typography/otspec/ttochap1.htm)

1. Name: created (https://github.com/prepare/FontRasterizer/blob/master/OpenTypeReader/Tables/NameEntry.cs)
2. Kern: created (https://github.com/prepare/FontRasterizer/blob/master/OpenTypeReader/Tables/Kern.cs)
3. Glyph Substitution table (GSUB) :developing ...
4. the Glyph Positioning table (GPOS): developing ...
5. the Baseline table (BASE): developing ...
6. the Justification table (JSTF), and
7. the Glyph Definition table (GDEF): developing ...

I've changed how to create each table.
see
https://github.com/prepare/FontRasterizer/blob/master/OpenTypeReader/OpenTypeReader.cs#L46

1. All tables are subclass of TableEntry (https://github.com/prepare/FontRasterizer/blob/master/OpenTypeReader/Tables/TableEntry.cs)
2. First, Load all as UnreadTableEntry
   ((https://github.com/prepare/FontRasterizer/blob/master/OpenTypeReader/OpenTypeReader.cs#L58)
3. and substitute some of them with actual table
   (https://github.com/prepare/FontRasterizer/blob/master/OpenTypeReader/OpenTypeReader.cs#L63)
4. I have created a Kern table and Name table

sample font
see

https://github.com/Ranks/emojione/tree/master/assets/fonts

https://github.com/eosrei/twemoji-color-font

https://emojione.com/

• port SharpFont's TrueType Hinting (https://github.com/MikePopoloski/SharpFont)
• implement this http://www.antigrain.com/research/font_rasterization/
• implement auto fit
• Documentation of our GlyphAnalysis and Hint technique

I know it’s not a big deal, but when I Alt-Tab through my windows, the VS instance I use for Typography appears as “MainDev”, which is not really descriptive. Any problem with renaming it to Typography.sln?

Hi, @prepare

I don't know how to get in touch with you so I created this issue. It seems you are not on gitter yet. Would you mind joining this gitter group? We can discuss about further development of Typography together.

I have published my GUI lib. A former version of Typography is included.

You can see how Typography is used in TypographyTextContext.

Currently the text size and postion got from TypographyTextContext is not accurate. I will look into this issue later.

PS: Don't worry about the LGPL license. I'll grant you a permissive license for codes that directly related to Typography.

see https://github.com/Chlumsky/msdfgen

https://commons.wikimedia.org/wiki/File:Printer_in_1568-ce.png

MAC/ Mono/Xamarin
Linux
Unity
XNA

Any idea when you'll be implementing Vertical Metrics support in OpenFont?

Does Typography support Xamarin.Forms yet?

see
https://www.microsoft.com/en-us/Typography/FontVariationsAnnouncement.aspx

https://alistapart.com/column/font-hinting-and-the-future-of-responsive-typography

https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369

https://opensource.googleblog.com/2016/09/introducing-opentype-font-variations.html

on win10, see Microsoft's new Bahnschrift

in #14

Now we can generate texture font for those who want to use it.
(eg in OpenGL/ OpenGLES app)

(see detail https://github.com/Chlumsky/msdfgen).

Can you suggest any texture font serialization file format?

currently I serialize it into a png image and xml description file

At line 114 in GlyphIndexList.cs, _tmpGlypIndexBackup may be empty if the whole string was replaced with a ligature, so the code crashes there when accessing _tmpGlypIndexBackup[0].

I might be able to fix this later, but I do not really understand GlyphIndexToUserChar yet. Maybe you know what’s going on and can fix it more quickly than me :-)

ensure that we can render all glyphs in Google's Noto Font.
see => https://github.com/googlei18n/noto-source

we can cache this

for faster glyph-sub/pos,

Implement as optional service (not in a core)
user can use it or not.

I've encountered some differences in the generation of MSDF bitmaps between this Typography library, and the original C++ MSDFGen implementation from which it is adapted.

With certain fonts (hand made ones, using FontForge) - certain glyphs are producing different MSDF maps - but it is only certain glyphs... the majority appear to be OK.

For example...

LayoutFarm - MSDFGen -

Look pretty much equivalent (apart from the page size, but that's fine)

However, the same code generating glyph:

LayoutFarm - MSDFGen -

Any idea what could be going on?

Font --- shardailes.zip

The current one is quite limited. I think as a text layout engine, at least the following functions should be added:

1. layout text characters as one or multiple lines inside a rectangle, including alignment (nine position)
2. given a point, get a index of the nearest character (hit-test)
3. given an index of character, get the position of the caret/cursor
4. reading direction-some languages reads from right to left
5. calculate the exact size of specified text without rendering them-in this case, the user only cares about how much space the layouted glyphs will occupy, so no contours need to be exacted and only the size of each glyph is required. In the following picture, the size of dashed rectangle printed glyphs is the exact size of 啊rAbc.
6. font family
7. font style/stretch/weight

Also many basic conceptions need to be documented, including

• coordinate system
• text position definition
• the scaling matters-I think it is related to dpi and the internal unit used in TrueType or OpenType.

How others design the text-layout API:

• DirectWrite provides IDWriteLayout.
• See how pango handles text-layout in a tutorial of Pango in GTK#.
• Also see how my DirectWrite C# warpper use DirectWrite.

@prepare's note
I make the tasks here ...

• 1) layout text characters as one or multiple lines inside a rectangle, including alignment (nine position)
• 2) given a point, get a index of the nearest character (hit-test) (see below)
• 3) given an index of character, get the position of the caret/cursor (see below)
• 4) reading direction-some languages reads from right to left
• 5) calculate the exact size of specified text without rendering them (see #23)
• 6) font family below...
• 7) font style, font weight below...

I think the project should be upgraded to VS2017 since it has been released.

The most important thing is that the support for .NET Standard(including .NET core) is greatly improved in VS2017. Also some project structures are changed. For example, project.json and *.xproj are no longer used. Instead, *.csproj is used for all C# projects in VS2017.

VS2017 can easily upgrade VS2015 solution and projects automatically. And I have done that on my machine.

I have been using VS2017 RC and RTM for several months. It provides more flexible installation and is smaller and quicker than the big VS2015. BTW, the android projects using Typography is written with VS2017--I can't install VS2015 on my machine because the remaining disk space is not enough.

I think it would be best to try to move out the ttf loader parts into a library, then you can just add a dependency from PixelFarm on that.

My artists have given me a new font that kills the importer - it appears to hit an NotImplementedException in GPOS.cs - at line 581.

The font has been authored in FontForge -- I'm not sure what to look for, or ask them to change to prevent the unsupported table format from being included.

Any suggestions?

How up to date is your C# implementation to Chlumsky's MSDFGen tool (on which it is based)?
Glyph generation from your implementation does not match, and results in very blocky curves.

I modified the edgeColoringSimple function to match the MSDFGen implementation.
I also modified the ConvertToIntBmp in MsdfGen.cs to write out the color channels in the correct order (argb) (Although BMP stores the bytes in ABGR order, Intel ordering when the uint32_t is written out, changes that order - so we write out a uint32_t of argb, so that when BMP reads it in byte-by-byte, it comes in a ABGR)

I also wrote a little function that converts a contour list to a MSDFGen shape definition, to test the possibility that your contour list was somehow causing the problem. So I use Typography.OpenFont to generate the shape definition, and then cut/paste the output into the commandline of MSDFGen.
Unfortunately, MSDFGen works just fine with that shape, so that confirms that the problem is with your C# implementation of MSDFGen.

I've compared the .cpp and .cs files, but I can't see where the divergence might be (admittedly, it was very very late at night)

(I've attached the DumpContours.cs for anyone that might find it useful)

I've also attached a couple of screenshots of the resultant MSDF glyph generated from both MSDFGen and Typeography.MSDFGen when run through the MSDF pixel shader.

contours.txt