Jomhuria: Project Outline, Kickoff

[Lasse Fister]

Hi Everybody,

I will work together with Kouroush on Jomhuria Font. A persian/arabic and latin, pretty bold display typeface.

We agreed with Dave to do the project planning and communication in the open via this list. Here is my initial draft for the project outline.

I will focus more on the engineering and tooling side while Kouroush will be more active on the design/language/content issues.

Starting Situation:

• We have a set of glyph drawings for Persian/Arabic and Latin glyphs.
• We know that Amiri by Khaled Hosny is very well engineered and libre http://www.amirifont.org/.
• While Jomhuria will probably not be as full featured as Amiri, we still want to use Amiri as our benchmark and blueprint.

Preparations:

• We'll work via GitHub. Kouroush will get an introduction to git from me and we'll figure out a mode how to work collaboratively on this project.
• I need to get amiri-font to build (at least) on my machines (I think I got most of the dependencies together, but a second approach to make Sorts Mill still needs to be done)

Initial Phase:

• A: Create a Fontforge font from Amiri without using the Amiri glyph drawings. We can probably use a well visible form for a "undefined" drawing and put the Amiri originals in the background layer, as reference.
• B: Start filling our new derivative file with glyph drawings, i.e. putting the glyphs in the right slots. Do a rough spacing, to ensure that the situation is not worse than it has to be.
• C: Adapt the Amiri build process for us (we should be able to build Amiri and to build our derivative alongside).
• D: Create documents for comparision (html and tex). Are there documents used by Amiri for similar purposes? Maybe we can make something in the spirit of http://testmyfont.com/ using Amiri as reference.

Main Phase, enter a loop:

1. Compile a list of tasks needed to make a proper font/improve the status quo, based on the reference documents (see C).
• Are glyphs missing?
• Overshoots, kerning (kerning will have to happen in later iterations)?
• How is GPOS and mark to mark performing?
• How is GSUB performing?
• Do we need further iteration over the the design of the latin and or arabic (harmonize the designs etc.)?
• Do we need more test documents?
• insert more ...
2. If there are any tasks: do them; then go back to 1). Else the project must be done.

That's it, for the start. Feel free to answer :-)

Lasse

-- 
Lasse Fister

Tel.: +49 (160) 949 106 15

Glückstraße 7
90763 Fürth

Visit www.graphicore.de

[Lasse Fister]

Good news Everyone!

Here is the current state:

We had a lengthy google hangout. I showed Kouruosh some git-kung-foo and we initialized a repository: https://github.com/Tarobish/Jomhuria in the end we decided that the graphical client provided by github (https://mac.github.com/) will be enough for a while.

I managed to build Sortsmill-Tools and Amiri on my local computer (a dependency introduced by Amiri). This is ok so far, however, I'm working on a repeatable process to build sortsmill-tools, baked  into a Dockerfile (http://docker.io), so that building Amiri and Jomhuria can be accomplished easier by others (and by me in case my computer crashes or such). The Dockerfile part is really easy, but building Sortsmill is still hard, even the second time :-(

Also, today I distilled fontforge files from the Amiri sources that will serve us as the foundation/blueprint for this project. I wrote a little python script for the task. The glyphs that contain outlines---and thus will be replaced with our drawings---are marked red. Everything else are composite-only glyphs, these will update automatically. The fonts contain distorted outline-font variations of the original drawings, to make it easier for Kouroush to find the right slots for the drawings and to make it easier to see how we progress.

This means we have done all "Preparations" and point A of the "Initial Phase" :-)

Kouroush will now work on B:

        "Start filling our new derivative file with glyph drawings, i.e. putting the glyphs in the right slots. Do a rough spacing, to ensure that the situation is not worse than it has to be."

And I continue with C:

        "Adapt the Amiri build process for us (we should be able to build Amiri and to build our derivative alongside)."

Lasse

[Dave Crossland]

Hi!

On 12 March 2015 at 09:37, Lasse Fister <la...@graphicore.de> wrote:

We had a lengthy google hangout. I showed Kouruosh some git-kung-foo and we initialized a repository: https://github.com/Tarobish/Jomhuria in the end we decided that the graphical client provided by github (https://mac.github.com/) will be enough for a while.

SparkleShare could also be a good fit.

 

I managed to build Sortsmill-Tools and Amiri on my local computer (a dependency introduced by Amiri). This is ok so far, however, I'm working on a repeatable process to build sortsmill-tools, baked  into a Dockerfile (http://docker.io), so that building Amiri and Jomhuria can be accomplished easier by others (and by me in case my computer crashes or such). The Dockerfile part is really easy, but building Sortsmill is still hard, even the second time :-(

I'm curious, what does Amiri need that Sortsmill has that FontForge doesn't?

 

Also, today I distilled fontforge files from the Amiri sources that will serve us as the foundation/blueprint for this project.

Does that mean you'll use FontForge going forwards?

 

I wrote a little python script for the task. The glyphs that contain outlines---and thus will be replaced with our drawings---are marked red. Everything else are composite-only glyphs, these will update automatically.

However, they may need to be manually created and re-positioned (and perhaps scaled.)

FontForge currently allows in SFD to have nested components, but currently won't generate them in TTF or CFF fonts.

 

The fonts contain distorted outline-font variations of the original drawings, to make it easier for Kouroush to find the right slots for the drawings and to make it easier to see how we progress.

Great!

 

This means we have done all "Preparations" and point A of the "Initial Phase" :-)

:)
 

 

Kouroush will now work on B:
        "Start filling our new derivative file with glyph drawings, i.e. putting the glyphs in the right slots. Do a rough spacing, to ensure that the situation is not worse than it has to be."

Cool. This is currently the glyph set that Google Fonts API subsets with - https://github.com/googlefonts/subsets/blob/master/arabic_unique-glyphs.nam - and this doesn't include the unencoded glyphs accessed via OTL, but it can provide a list of higher priority glyphs to start with, as I believe the Amiri character set is a superset of this list.

 

And I continue with C:
        "Adapt the Amiri build process for us (we should be able to build Amiri and to build our derivative alongside)."

Cheers

Dave

[K-B-STUDIO]

Hi :)

Great

well, my part just start :) I’m trying to do my best as soon as possible

Cheers

Kourosh

[Lasse Fister]

On 12.03.2015 05:35, Dave Crossland wrote:

 

I'm curious, what does Amiri need that Sortsmill has that FontForge doesn't

I have seen some new python api calls, see https://github.com/khaledhosny/amiri-font/commit/0f038f9e14988fcef0e838c6b51c8cbe96cc6d98. Also fontforge crashes when building amiri (after replacing the api calls). Which seems like a bug when a glyph is missing but referenced in the features or so (I don't remember exactly)

I can't judge whether the output is different.

 

Also, today I distilled fontforge files from the Amiri sources that will serve us as the foundation/blueprint for this project.

Does that mean you'll use FontForge going forwards?

Fontforge for glyph authoring and probably sortsmill-tools for building (I'll distill what we need from Amiris build setup, then we can see how much is left anyways).

I think for task automation both is good, using the python api. If I need to I'll switch to ufo. I'm still learning what Khaled does there with Amiri ...

 

I wrote a little python script for the task. The glyphs that contain outlines---and thus will be replaced with our drawings---are marked red. Everything else are composite-only glyphs, these will update automatically.

However, they may need to be manually created and re-positioned (and perhaps scaled.)

Yes, of course, this is just our starting point! We'll adjust and judge as soon as we enter the main-loop, after the bootstrapping ;-)

FontForge currently allows in SFD to have nested components, but currently won't generate them in TTF or CFF fonts.

The amiri build script takes care of that: https://github.com/khaledhosny/amiri-font/blob/master/tools/build.py#L59

 

The fonts contain distorted outline-font variations of the original drawings, to make it easier for Kouroush to find the right slots for the drawings and to make it easier to see how we progress.

Great!

 

If anyone is interested in this, the script is in the repository. I could make a more general tool from it if needed. It uses fontforge, some robofab pens and it's own pens.

[Khaled Hosny]

On Thu, Mar 12, 2015 at 10:05:43AM +0530, Dave Crossland wrote:
> > I wrote a little python script for the task. The glyphs that contain
> > outlines---and thus will be replaced with our drawings---are marked red.
> > Everything else are composite-only glyphs, these will update automatically.
> >
>
> However, they may need to be manually created and re-positioned (and
> perhaps scaled.)
>
> FontForge currently allows in SFD to have nested components, but currently
> won't generate them in TTF or CFF fonts.

FontForge generates nested components in TTF just fine (at least it did
so at the time we forked it) but there is an issue with the transformed
nested components on Mac OS X where the transformations seems to be
ignored, so in Amiri I flatten all the references at build time. (I
think I should try to figure out why the transformations were broken on
Mac OS X, when this was first reported to me I didn’t have access to
such systems).

No idea about CFF fonts (given that in CFF there is no concept of
components, and FontForge probably converts them to subroutines).

Regards,
Khaled

[Dave Crossland]

Hi

On 12 March 2015 at 00:07, Lasse Fister <la...@graphicore.de> wrote:

Kouroush will now work on B:
        "Start filling our new derivative file with glyph drawings, i.e. putting the glyphs in the right slots. Do a rough spacing, to ensure that the situation is not worse than it has to be."

And I continue with C:
        "Adapt the Amiri build process for us (we should be able to build Amiri and to build our derivative alongside).

How is it going? :)

--

Cheers
Dave

[Lasse Fister]

I finished C) on Friday. We can build, make the documentation pdf with XeTeX and all tests pass (after some "lost" anchor points are added back.) All from Docker. The XeTeX part is especially nice, because because we can use it to make the DDT documents. Which leads to D) the preparation of Documents

Kouroush posted the Arabic/Persian char-set, but he saved it to the  wrong location.
@Kouroush: Can you please move "Persian - Arabic.sfdir" to "sources/jomhuria.sfdir" and replace the old file that is there already.

[Dave Crossland]

Great! Looking forward to seeing the PDF proofs shortly :)

--
--
Google Font Directory Discussions
http://groups.google.com/group/googlefontdirectory-discuss

---
You received this message because you are subscribed to the Google Groups "Google Font Directory Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefontdirectory...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kourosh Beigpour]

On Monday, 23 March 2015 04:49:13 UTC-7, Lasse Fister wrote:

On 23.03.2015 06:17, Dave Crossland wrote:

On 12 March 2015 at 00:07, Lasse Fister <la...@graphicore.de> wrote:

Kouroush will now work on B:
        "Start filling our new derivative file with glyph drawings, i.e. putting the glyphs in the right slots. Do a rough spacing, to ensure that the situation is not worse than it has to be."

And I continue with C:
        "Adapt the Amiri build process for us (we should be able to build Amiri and to build our derivative alongside).

How is it going? :)

I finished C) on Friday. We can build, make the documentation pdf with XeTeX and all tests pass (after some "lost" anchor points are added back.) All from Docker. The XeTeX part is especially nice, because because we can use it to make the DDT documents. Which leads to D) the preparation of Documents

Kouroush posted the Arabic/Persian char-set, but he saved it to the  wrong location.
@Kouroush: Can you please move "Persian - Arabic.sfdir" to "sources/jomhuria.sfdir" and replace the old file that is there already.

@Lasse: i just replaced the files. for now, I'm working on the Latin part. i think it will be done by tomorrow.

can't wait to see the PDF proof :)

[Dave Crossland]

On 23 March 2015 at 12:56, Kourosh Beigpour <taro...@gmail.com> wrote:
> I'm working on the Latin part. i think it will be done by tomorrow.
> can't wait to see the PDF proof :)

What's the latest?

[Kourosh Beigpour]

so far we are done with the latin part. PDF proof is ready. for, now we are working on the blanks & kerning. the main problem is, a number of feature in Amiri :) 

[Dave Crossland]

Hi

What's the latest? :) 

Would be great to see the PDFs in the repo at https://github.com/Tarobish/Jomhuria :) 

--

Cheers
Dave

[Lasse Fister]

> What's the latest? :)

I had some wrestling with Fontforge and Sortsmill compatibility. But it
seems like we have a workaround. I should file a bug at Sortsmill and
Fontforge and let the projects work out who has to fix it :-/

Fontforge on the mac seems to be deleting spacing characters for no
reason. But we did not yet figure out what action exactly causes this.
May be related to the sortsmill compatibility stuff.

We had some issues with our git collaboration. Sparkleshare and the
Github client seem both hard to use for someone with zero git knowledge.
Especially Sparkleshare caused some chaos. The last time we tried, the
videochat did not work properly, which was a painful session thus.

I adapted the "doc" target of our Makefile to generate a .pdf for each
.tex that we have.

Kourosh filled a lot of blanks in the project and we can now display
almost all that Amiri can. Also, Kourosh did the positioning of a lot
diacritical marks in all the component characters (K referred to this as
"kerning"). I also think this stuff should be done using anchors, and
I'm a bit confused why Amiri is doing all this with components instead
of OpenType. (there are probably helpful scripts as a starter like:
https://github.com/Tarobish/Jomhuria/blob/master/tools/build_compat.py
or
https://github.com/Tarobish/Jomhuria/blob/master/tools/rebuild_composite.py)

Kourosh also wants to delete some characters from Jomhuria but I am
waiting for more information about this: Which characters? Why are they
there in the first place, if we can delete them now. What does it mean
to delete them? What should we do instead of using these characters? One
problem of deleting characters is that we have to author some open type
tables as well. So this is more work than it sounds like.
Also, we've seen a much leaner font in terms of character count. I
wonder whether such a leaner approach would still be sufficient and
whether we loose important features when doing it that way. However, I
don't have the time to study arabic/persian writing systems right now.

> Would be great to see the PDFs in the repo
> at https://github.com/Tarobish/Jomhuria :)

https://github.com/Tarobish/Jomhuria/tree/master/generated/documents

I'd like to generate HTML documents out of the tex files as well. These
should use our web-fonts of course. I've found something at
http://tex.stackexchange.com/a/44396 and I hope I can make it work for us.

@Kouroush did you collect more texts etc. that we can use in the meantime?

I think the latin spacing needs to be done. And the lowercase e needs an
overhaul.

[K-B-STUDIO]

On Apr 13, 2015, at 9:36 AM, Lasse Fister <la...@graphicore.de> wrote:

What's the latest? :)

I had some wrestling with Fontforge and Sortsmill compatibility. But it
seems like we have a workaround. I should file a bug at Sortsmill and
Fontforge and let the projects work out who has to fix it :-/

Fontforge on the mac seems to be deleting spacing characters for no
reason. But we did not yet figure out what action exactly causes this.
May be related to the sortsmill compatibility stuff.

We had some issues with our git collaboration. Sparkleshare and the
Github client seem both hard to use for someone with zero git knowledge.
Especially Sparkleshare caused some chaos. The last time we tried, the
videochat did not work properly, which was a painful session thus.

I adapted the "doc" target of our Makefile to generate a .pdf for each
.tex that we have.

Kourosh filled a lot of blanks in the project and we can now display
almost all that Amiri can. Also, Kourosh did the positioning of a lot
diacritical marks in all the component characters (K referred to this as
"kerning”).

oh no :) as a kerning, i mean spacing between all glyphs.  

I also think this stuff should be done using anchors, and

i tried i can fix the diacritic marks position by changing the position of anchors :)

I'm a bit confused why Amiri is doing all this with components instead
of OpenType. (there are probably helpful scripts as a starter like:
https://github.com/Tarobish/Jomhuria/blob/master/tools/build_compat.py
or
https://github.com/Tarobish/Jomhuria/blob/master/tools/rebuild_composite.py)

Kourosh also wants to delete some characters from Jomhuria but I am
waiting for more information about this: Which characters? Why are they
there in the first place, if we can delete them now. What does it mean
to delete them? What should we do instead of using these characters? One
problem of deleting characters is that we have to author some open type
tables as well. So this is more work than it sounds like.

no :) i mean character from Amiri :) some how our current version its mixed of Amiri and jomhuria 

please check the picture (the outline glyphs belong to Amiri, its not ours) 

the problem is we don’t have the in the table but in the documentation, they are every where 

thats what i mean :)

Also, we've seen a much leaner font in terms of character count. I

wonder whether such a leaner approach would still be sufficient and
whether we loose important features when doing it that way. However, I
don't have the time to study arabic/persian writing systems right now.

Would be great to see the PDFs in the repo
at https://github.com/Tarobish/Jomhuria :)

https://github.com/Tarobish/Jomhuria/tree/master/generated/documents

I'd like to generate HTML documents out of the tex files as well. These
should use our web-fonts of course. I've found something at
http://tex.stackexchange.com/a/44396 and I hope I can make it work for us.

@Kouroush did you collect more texts etc. that we can use in the meantime?

i just did some, its in the document-sources

please let me know if it works

I think the latin spacing needs to be done. And the lowercase e needs an
overhaul 

ill work on spacing 

--
Lasse Fister

Tel.: +49 (160) 949 106 15

Glückstraße 7
90763 Fürth

Visit www.graphicore.de

<0xF067AF71.asc>

[Khaled Hosny]

On Mon, Apr 13, 2015 at 06:36:20PM +0200, Lasse Fister wrote:
>
> > What's the latest? :)
> I had some wrestling with Fontforge and Sortsmill compatibility. But it
> seems like we have a workaround. I should file a bug at Sortsmill and
> Fontforge and let the projects work out who has to fix it :-/

I’d be interested to know about that.

> Kourosh filled a lot of blanks in the project and we can now display
> almost all that Amiri can. Also, Kourosh did the positioning of a lot
> diacritical marks in all the component characters (K referred to this as
> "kerning"). I also think this stuff should be done using anchors, and
> I'm a bit confused why Amiri is doing all this with components instead
> of OpenType.

Initially I was doing the dot positioning dynamically[1], but things got
complex over time and I ended up hitting bugs in almost all OpenType
implementations, so I “flattened” all such uses of the anchors (leaving
them only for vowel marks) using some ad hock scripts and manually
repositioning the odd cases. The anchors are still there and I use them
when adding new “composite” Arabic characters to position the
components.

> (there are probably helpful scripts as a starter like:
> https://github.com/Tarobish/Jomhuria/blob/master/tools/build_compat.py

This builds the Arabic Presentation Forms-A and B compatibility blocks,
they are legacy characters that most fonts can do without them. They are
in Amiri for historical reasons (some broken browsers used to reject
fonts not having them in the bast, but no browser that matters does this
now) and for completeness sake since one of Amiri’s goals is to cover
each Arabic character in Unicode (though it have been lagging behind for
sometime and the inability to dynamically position the anchors makes
adding some new characters harder than it should be.

> or
> https://github.com/Tarobish/Jomhuria/blob/master/tools/rebuild_composite.py)

That is the one you need. Though you might need to adjust it a bit (I
have few more scripts that are not on the repo and I can send you if
needed to serve as examples).

> Kourosh also wants to delete some characters from Jomhuria but I am
> waiting for more information about this: Which characters? Why are they
> there in the first place, if we can delete them now. What does it mean
> to delete them? What should we do instead of using these characters? One
> problem of deleting characters is that we have to author some open type
> tables as well. So this is more work than it sounds like.

One way is to do post-processing using pyftsubset to keep only the
characters you want and it should handle subsetting the OpenType tables
for you.

Regards,
Khaled

1. http://khaledhosny.org/node/178

[Lasse Fister]

On 13.04.2015 20:36, K-B-STUDIO wrote:

On Apr 13, 2015, at 9:36 AM, Lasse Fister <la...@graphicore.de> wrote:

Kourosh filled a lot of blanks in the project and we can now display
almost all that Amiri can. Also, Kourosh did the positioning of a lot
diacritical marks in all the component characters (K referred to this as
"kerning”).

oh no :) as a kerning, i mean spacing between all glyphs.  

Ah, good. I was wondering, but didn't observe the spacing so I just did not notice :-) Still we may have the problem that the old kerning data of Amiri is still in there. That could be a not optimal situation for judging the final spacing.

no :) i mean character from Amiri :) some how our current version its mixed of Amiri and jomhuria 

please check the picture (the outline glyphs belong to Amiri, its not ours) 

the problem is we don’t have the in the table but in the documentation, they are every where 

thats what i mean :)

Ahh, I see :) They are not in the glyph table pdf because they are displayed by OpenType rules performing contextual replacements. The table pdf file shows only all unicode encoded glyphs, but OpenType can use glyphs without unicode encoding, just by referencing their name.
They are marked red in Fontforge. If you click "Encoding->compact" in Fontforge, it should be easy for you to spot the red glyphs. However, it's probably legitimate not to have all of them in the font. So maybe we need a downgrade strategy.

[Lasse Fister]

Thanks Khaled for the info! I will digest it.

On 13.04.2015 20:50, Khaled Hosny wrote:
> On Mon, Apr 13, 2015 at 06:36:20PM +0200, Lasse Fister wrote:
>>> What's the latest? :)
>> I had some wrestling with Fontforge and Sortsmill compatibility. But it
>> seems like we have a workaround. I should file a bug at Sortsmill and
>> Fontforge and let the projects work out who has to fix it :-/
> I’d be interested to know about that.

It took a while to find this :-) Fontforge saves empty background Layers
like this:

Back
Fore
... data

Sortsmill seems not to like that and doesn't load the Foreground Layer
splines.

So I do essentially replace("Back\nFore", "Fore") for every glyph file
in here:
https://github.com/Tarobish/Jomhuria/blob/master/tools/removeEmptyBackgroundLayers.py

Fontforge will rewrite the empty "Back" always, so I have to run this
script each time when Kourosh did work on the fonts.

L.

[K-B-STUDIO]

Hi Khaled

happy to hear from you :)
i need your help about metric and kerning in Arabic

i tried a few times but i didn’t found anything to solve it.
my main problem is, how can i have arabic letterforms in the kerning window and how can i create kerning classes?

best
Kourosh

[Dave Crossland]

On 14 April 2015 at 15:59, K-B-STUDIO <taro...@gmail.com> wrote:

 my main problem is, how can i have arabic letterforms in the kerning window and how can i create kerning classes?

In FontForge, Metrics menu, Kern by Classes, New Lookup, click the blue New, select Horizontal Kerning, OK, OK, in the First Char list click the dropdown arrow on the right side of the <New> item, hold Shift to select glyphs for the class, click ok. In the Second Char, so the same. Then you can select a cell in the table below, and kern it using the preview on the right. 

[Lasse Fister]

On 04/14/2015 09:59 PM, K-B-STUDIO wrote:

how can i have arabic letterforms in the kerning window

You can also drag them from the glyph overview into the Metrics window.

and how can i create kerning classes?

There's documentation with some screenshots : http://designwithfontforge.com/en-US/Spacing_Metrics_and_Kerning.html#kerning-with-classes

[Kourosh Beigpour]

Hi everybody,

I'd like to update everyone on the progress so far..

We are currently working on the third draft. We did several test, changes, and so forth. We had some complications with the FontForge, FontForge had conflict with OX and deleting space from Jomhiria itself.

Lasse did some coding to revert data from the old file, he is currently trying to resolve the issue. A final test will be performed to insure its availability on the Repository generated folder.

Our current test includes: Persian, Arabic, Urdu and Punjabi with the Latin version to see every possible connection.

https://github.com/Tarobish/Jomhuria

For now, our main problem comes from our source (as we know, we chose Amiri as a source. Khaled did a magnificent job with Amiri and we thought we can use his code as a source to save time) but we have some complications with choosing Amiri since its a complicated Font. It includes 3000 glyphs and contextual, however, our font doesn't need all of these. We have a simple and bold font based on the Naskh which would be good for tittles, magazine and so forth.

Our current version, is mixed of Amiri and Jomhuria because of contextual. Lasse is  trying to find a way to delete them all and at the same time not spoil the font. After this part we can work on the spacing and kerning, then marks and  vowel positions in our Arabic Version. At the end we can test on another draft and work on the details. We also figured out that rtl kerning in FontForge is fundamentally broken, Khaled said we have to write contextual positioning rule and use his font viewer to test.

https://github.com/khaledhosny/fontview

[Khaled Hosny]

FontForge’s kerning for RTL text is fundamentally flawed (in Sorts Mill
I recently removed it completely because it is unfixable).

But I hardly need it since I write all my feature file code directly, so
I write the code by hand, keep the font open in fontview[1] (any other
font viewer with OpenType support that auto updates when the file
changes should do), build the font, check the kerning and repeat the
cycle.

RTL kerning in OpenType is a bit tricky as well and it took me a while
to figure it out, basically when kerning an RTL pair, instead of just
modifying the width of the first glyph (the rightmost one), you have to
modify its X position as well, since glyph positioning in OpenType is
applied from left to right regardless of the text direction.

Regards,
Khaled

1. https://github.com/khaledhosny/fontview

[Khaled Hosny]

On Fri, Apr 17, 2015 at 04:44:16PM -0700, Kourosh Beigpour wrote:
> Khaled said we have to write contextual positioning rule and use his
> font viewer to test.

Contextual positioning is not required, but it tends to decrease font
size when there are many kerning pairs on the font (one can’t use
kerning classes with RTL kerning as it does not allow adjusting X
position, only the width).

Regards,
Khaled

[Dave Crossland]

Hi

On 17 April 2015 at 19:46, Khaled Hosny <khale...@eglug.org> wrote:

RTL kerning in OpenType is a bit tricky as well and it took me a while
to figure it out, basically when kerning an RTL pair, instead of just
modifying the width of the first glyph (the rightmost one), you have to
modify its X position as well, since glyph positioning in OpenType is
applied from left to right regardless of the text direction.

(In the Metapolator UI, the spacing model is presented by Peter Sikking as front/back instead of left/right.)

--

Cheers
Dave

[Dave Crossland]

Hi

What's the latest? :)

Cheers
Dave

[Dave Crossland]

Worth a look at Khaled's new Aref: https://github.com/khaledhosny/aref-ruqaa

[Dave Crossland]

I also wonder if using https://github.com/simoncozens/sile for typesetting the testing document PDFs could be interesting in the future :)

[Adam Twardoch (List)]

Given that SILE's "show-off file" ( https://raw.githubusercontent.com/simoncozens/sile/master/examples/showoff.pdf ), the user's manual ( http://www.sile-typesetter.org/images/sile-0.9.1.pdf ) and the SILE website ( http://www.sile-typesetter.org/ ) all look atrocious, I wonder what the rationale would be. It's a completely insular solution. It allows you to write your input files in a TeX-like syntax (which seems to be preferred) but does not allow you to use the vast repository of existing TeX or LaTeX formats, packages etc. Alternatively, it allows you to write your input in a SILE-specific XML flavor. And it's written in Lua, which is an insular language, completely foreign to most users (who may have some knowledge of JS or Python at most).

If one knows HTML and CSS, it's much better to use http://wkhtmltopdf.org/ or http://www.princexml.com/ — which both take HTML (with JS) and print-media CSS and output PDF documents.

If one knows TeX, it's much better to use ConTeXt or LaTeX with XeTeX. This is a well-supported, super-stable environment, uses HarfBuzz for OpenType layout and has a huge community.

Two years ago, I've designed a scientific journal (with Charis SIL and Playfair as the main ingredients). The design has been implemented using XeTeX, and the results are rather decent:
http://jlm.ipipan.waw.pl/index.php/JLM/article/download/48/50
http://jlm.ipipan.waw.pl/index.php/JLM/article/download/62/51

Here's a few font-related pointers on XeTeX and ConTeXt:
http://nitens.org/taraborelli/latex
http://www.simon-cozens.org/content/why-all-biblical-studies-people-should-learn-xetex
http://wiki.contextgarden.net/Fonts_in_XeTeX

There's PythonTeX that allows to intermix LaTeX with Python:
https://github.com/gpoore/pythontex

Here are some decent examples of XeTeX used for typographic purposes:
https://www.tug.org/texshowcase/winawer.pdf
https://www.tug.org/texshowcase/pp.pdf
https://www.tug.org/texshowcase/onetype.pdf
https://www.tug.org/texshowcase/csky-sample.pdf

Here's some more stuff focusing on XeTeX:
http://xml.web.cern.ch/XML/lgc2/xetexmain.pdf
http://linuxlibertine.sourceforge.net/Libertine-XeTex-EN.pdf
http://scholarsfonts.net/xetextt.pdf
http://faculty.washington.edu/cadolph/software/caxetexBook.pdf
ftp://ftp.gust.org.pl/TeX/info/xetexref/xetex-reference.pdf
http://piotrkosoft.net/pub/mirrors/CTAN/macros/latex/contrib/polyglossia/polyglossia.pdf
http://mirror.unl.edu/ctan/macros/latex/contrib/microtype/microtype.pdf
ftp://ftp.gust.org.pl/TeX/macros/latex/contrib/tufte-latex/sample-book.pdf

But overall, I think getting into the TeX world may be a bit overwhelming for most people.

I think PrinceXML offers a good starting point:
http://www.princexml.com/

Alternatively, one could use wkhtmltopdf which even has a neat Python binding:
http://wkhtmltopdf.org/
https://github.com/JazzCore/python-pdfkit

wkhtmltopdf hasn't been used very seriously so far in high-quality design applications but I think the HTML+CSS -> PDF route is generally the most future-proof. TeX isn't, really, and neither are TeX "rewrites" of any kind.

Best,
Adam

> On 04 May 2015, at 01:15, Dave Crossland <da...@lab6.com> wrote:
>
> I also wonder if using https://github.com/simoncozens/sile for typesetting the testing document PDFs could be interesting in the future :)
>

[Lasse Fister]

(This is a crosspost to keep this thread alive, I initially posted there: https://groups.google.com/forum/#!topic/googlefonts-discuss/l7GRG26N848)

Hi Kourosh, Hi List

hi hope you are doing well and your flight back home from LGM was good!
I was a bit jet-lagged/destroyed at the beginning of the week but I almost recovered.

Last week at the LGM in Toronto Kourosh and I had a working session where we got most of the font into a much better shape. That involved removing many OpenType features that Amiri defines but that are too much for Jomhuria. Following that I wrote two scripts to clean up a bit:

1. remove classes from classes.fea file that are not in use anymore (because we removed some features)
2. remove glyphs from the font that are not accessible anymore

Not accessible glyphs means:

1. no unicode value
2. the name is not mentioned in the *.fea files
3. not referenced by other accessible glyphs

I removed 2537 glyphs. Now there are 3536 glyphs left. That means we just got rid of 42% of the font, that's a good diet!

Kourosh, I want you to do 2 things:

1. Check if I deleted too much. See the commit message for a list: https://github.com/Tarobish/Jomhuria/commit/6be89b7a400c666dcd74d34391b86b468c4dd55d And tell me if something should still be in the font, so that I can get it back.
2. Make a list of glyphs that we don't need anymore. It is enough if you color-code them, use #0000ff (the shiny bright green color-swatch in "Glyph Info -> Comment") And I will find them :-)

Please check out the current version of the font and inspect it yourself. You will see that there are still outlined glyphs from Amiri in it. I believe we can clean up even more! However, I'll need your guidance for that.

Then, after 2. I can see what needs to be done to remove these glyphs. We need to remove them from the feature files, then my script can do the rest. However, I want to make sure we don't break anything. I will look into that and then we can make a hangout to work on the details.

I think we shouldn't remove glyphs that have a unicode value, because that is useful information and we already have it, so I'd like to keep it if this does not create extra work. Most of the unicode encoded glyphs are composites anyways.

I found a very useful tool in Fontforge:
In a Glyph Editor Window:
"Element -> Show Dependent -> References"
Will give you a list of links where your current glyph is used as a component.

Cheers, Lasse

[Lasse Fister]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, here the latest:

Last week Kourosh marked some glyphs for removal in the font. I wrote some tool to help me me understand the situation and removed in a semi-automated fashion all of the marked glyphs and some more that became inaccessible. I tried not to wreck the font and the build process on my way.

I removed more glyphs than the marked ones, because some became inaccessible on my way. After this session the font has 1368 less glyphs and counts now 2168 glyphs. That's a reduction by ~39% Overall we got rid of 3905 that are not needed for Jomhuria.

@Kourosh I pushed all to the master branch https://github.com/Tarobish/Jomhuria including the newly generated documents. Please see if the font is still in tact or if I broke something.

Lasse

On 05/08/2015 10:21 AM, Kourosh Beigpour wrote:
>
>
> On Thursday, 7 May 2015 16:31:26 UTC-7, Lasse Fister wrote:
>
>     Hi Kourosh, Hi List
>
> Hi Lasse, hi everyone

>
>
>     hi hope you are doing well and your flight back home from LGM was good!
>

> Thanks ;) I'm doing great, it was great, hope you had a good flight too
> it was great to seeing you, and spending time with you :)

> 
>
>     I was a bit jet-lagged/destroyed at the beginning of the week but I almost recovered.
>

> same here, i was off for a 3 days

>
>
>     Last week at the LGM in Toronto Kourosh and I had a working session where we got most of the font into a much better shape. That involved removing many OpenType features that Amiri defines but that are too much for Jomhuria. Following that I wrote two scripts to clean up a bit:
>

>      1. remove classes from classes.fea file that are not in use anymore (because we removed some features)
>      2. remove glyphs from the font that are not accessible anymore
>
>     Not accessible glyphs means:
>
>      1. no unicode value
>      2. the name is not mentioned in the *.fea files
>      3. not referenced by other accessible glyphs

>
>     I removed 2537 glyphs. Now there are 3536 glyphs left. That means we just got rid of 42% of the font, that's a good diet!
>
>     Kourosh, I want you to do 2 things:
>

>      1. Check if I deleted too much. See the commit message for a list: https://github.com/Tarobish/Jomhuria/commit/6be89b7a400c666dcd74d34391b86b468c4dd55d <https://github.com/Tarobish/Jomhuria/commit/6be89b7a400c666dcd74d34391b86b468c4dd55d> And tell me if something should still be in the font, so that I can get it back.
>
> i just checked the font and generated document, looks perfect. i didn't find anything wrong 
>
>      1. Make a list of glyphs that we don't need anymore. It is enough if you color-code them, use #0000ff (the shiny bright green color-swatch in "Glyph Info -> Comment") And I will find them :-)
>
> For sure, i started to mark the glyphs that we don't need any more. i just need a days to get it down. at the same time I'm workin gone the spacing. i didn't commit till finish them all :)
> you will have them by tomorrow

>
>     Please check out the current version of the font and inspect it yourself. You will see that there are still outlined glyphs from Amiri in it. I believe we can clean up even more! However, I'll need your guidance for that.
>

> yeah for sure we can clean it more

> 
>
>     Then, after 2. I can see what needs to be done to remove these glyphs. We need to remove them from the feature files, then my script can do the rest. However, I want to make sure we don't break anything. I will look into that and then we can make a hangout to work on the details.
>

> perfect :)

>
>
>     I think we shouldn't remove glyphs that have a unicode value, because that is useful information and we already have it, so I'd like to keep it if this does not create extra work. Most of the unicode encoded glyphs are composites anyways.
>
>     I found a very useful tool in Fontforge:
>     In a Glyph Editor Window:
>     "Element -> Show Dependent -> References"
>     Will give you a list of links where your current glyph is used as a component.
>

> great, ill check it for sure
>
> many thanks
> Kourosh

>
> For more options, visit https://groups.google.com/d/optout.

On 05/08/2015 02:33 AM, Lasse Fister wrote:

> (This is a crosspost to keep this thread alive, I initially posted there: https://groups.google.com/forum/#!topic/googlefonts-discuss/l7GRG26N848)
>
> Hi Kourosh, Hi List
>
> hi hope you are doing well and your flight back home from LGM was good!
> I was a bit jet-lagged/destroyed at the beginning of the week but I almost recovered.
>
> Last week at the LGM in Toronto Kourosh and I had a working session where we got most of the font into a much better shape. That involved removing many OpenType features that Amiri defines but that are too much for Jomhuria. Following that I wrote two scripts to clean up a bit:
>

>  1. remove classes from classes.fea file that are not in use anymore (because we removed some features)
>  2. remove glyphs from the font that are not accessible anymore
>
> Not accessible glyphs means:
>
>  1. no unicode value
>  2. the name is not mentioned in the *.fea files
>  3. not referenced by other accessible glyphs

>
> I removed 2537 glyphs. Now there are 3536 glyphs left. That means we just got rid of 42% of the font, that's a good diet!
>
> Kourosh, I want you to do 2 things:
>

>  1. Check if I deleted too much. See the commit message for a list: https://github.com/Tarobish/Jomhuria/commit/6be89b7a400c666dcd74d34391b86b468c4dd55d And tell me if something should still be in the font, so that I can get it back.
>  2. Make a list of glyphs that we don't need anymore. It is enough if you color-code them, use #0000ff (the shiny bright green color-swatch in "Glyph Info -> Comment") And I will find them :-)

>
> Please check out the current version of the font and inspect it yourself. You will see that there are still outlined glyphs from Amiri in it. I believe we can clean up even more! However, I'll need your guidance for that.
>
> Then, after 2. I can see what needs to be done to remove these glyphs. We need to remove them from the feature files, then my script can do the rest. However, I want to make sure we don't break anything. I will look into that and then we can make a hangout to work on the details.
>
> I think we shouldn't remove glyphs that have a unicode value, because that is useful information and we already have it, so I'd like to keep it if this does not create extra work. Most of the unicode encoded glyphs are composites anyways.
>
> I found a very useful tool in Fontforge:
> In a Glyph Editor Window:
> "Element -> Show Dependent -> References"
> Will give you a list of links where your current glyph is used as a component.
>
>

- --

Lasse Fister

Tel.: +49 (160) 949 106 15

Glückstraße 7
90763 Fürth

Visit www.graphicore.de

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVVkuWAAoJEPwfsHnwZ69xTx4QAMwTgI94bTm/t9E3prZNzWig
R4oCWS1ZVhi1W2ve4xLzW0PQzpB7T3J5R1P+FsDS186nzK/kXR7FZKNp/RremPbG
SpMVAoP9R2zP6dhA6fLFrwqr2YXtMELBsqXWjWydGGB5E7wwHy8NHbiz528grwpc
r0g9hBETQ+gnQO2FzFqyBj2+E8LiYE4S5MeXThpzLW3ob8BmCeR21BXagUTa5OGb
s5sVr2b96H8+IadtC546KBu3k+a6QTk0tjH+LaVrRx+DGqZqfWQF5dh1oWBKKyUN
QLwdNr49zGfnCtnfaamtsHhwDZ4B4/TEUziNvAHeBiDK9JWMp7A+HXYhTMZJuFm1
UiAsHTihMrMqeLXY3fZfmf7QuI/gNVTxi0sPmHSuaeFjfEX3cOAFonpQEIGyxw6c
GJLJ+eVJcqiBxPQnt5ennrxyT5vrbc9I3dJ6LReq4qL7i5W9QKLuZ1CqjdJMPzwi
7L2eWW0gDwT0+OTelErL8ueuvDxmPf4j8dUPlBqWC6A9oQ/N/iRGgwYxHimUTDk/
YPvjkxhMd+AdA+ZH+WUPMnvuzHwIdSrELxIw3JMgP3X22Lpnobe856Of0PP24YVX
dwAfYwj/dUPNoIRBuluiPABi+WeiPtf+AUaai7eNFgfAsi3v2DC6p0E6TyLsJc4Z
Hk0zZ1KGlqzWbGTbTMwz
=D9hx
-----END PGP SIGNATURE-----

[Dave Crossland]

Hi

This sounds good. I can review with Khaled and Gaber (yype designers here in Cairo) tomorrow at 11am germany time.

What are the next steps?

Cheers
Dave

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To post to this group, send email to googlefon...@googlegroups.com.
Visit this group at http://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/55564BA3.1050503%40graphicore.de.

[Lasse Fister]

On 05/15/2015 10:46 PM, Dave Crossland wrote:

> What are the next steps?

Review sounds good. I guess it's evaluation time. I think Kourosh was about to fix some more spacing issues and he has to check if I broke something.

It would be good if we could identify the tasks needed to finish the font. That includes deciding how to proceed with the Latin.

L.

[Dave Crossland]

Hi everyone

On 15 May 2015 at 23:09, Lasse Fister <la...@graphicore.de> wrote:

It would be good if we could identify the tasks needed to finish the font. That includes deciding how to proceed with the Latin.

Sounds good. 

So, Kourosh has developed the beginning of a Latin to go with Jomhuria, which is a titling boldface. It needs some work by a trained type designer to make it really work well, and Lasse's budget included a segment for this to be done either as a collaboration with Kourosh (who is keen to learn) or as a subcontracted part of the work with Kourosh as a consultant. I believe you discussed this with Eben in Toronto, although I'm not sure how far the discussions got.

Indeed, having spent a week in Cairo, I'm not 100% sure about the style of the design Kourosh has made; this style is very widely used, and I wonder that exploring alternatives that are more historical Latin serif styles might be worthwhile. Eg, I think perhaps a modification of https://www.google.com/fonts/specimen/Abril+Fatface (or some other display text boldface) could work well. But equally I'm happy to use Kourosh's design, too.

So now that the Arabic is wrapping up, it would be good to get this underway. 

Kourosh, is the latest Latin committed to git and pushed to Github? I believe you were going to work on it further with what you've learned recently, and to use Glyphs 2. Let us know where we can evaluate the latest version and compare to the other options :) 

Cheers,
Dave

[K-B-STUDIO]

Hi Everyone 

On May 15, 2015, at 5:36 PM, Dave Crossland <dcros...@google.com> wrote:

Hi everyone

On 15 May 2015 at 23:09, Lasse Fister <la...@graphicore.de> wrote:

It would be good if we could identify the tasks needed to finish the font. That includes deciding how to proceed with the Latin.

Sounds good. 

So, Kourosh has developed the beginning of a Latin to go with Jomhuria, which is a titling boldface. It needs some work by a trained type designer to make it really work well, and Lasse's budget included a segment for this to be done either as a collaboration with Kourosh (who is keen to learn)

i would love to do that

or as a subcontracted part of the work with Kourosh as a consultant. I believe you discussed this with Eben in Toronto, although I'm not sure how far the discussions got.

Indeed, having spent a week in Cairo, I'm not 100% sure about the style of the design Kourosh has made; this style is very widely used, and I wonder that exploring alternatives that are more historical Latin serif styles might be worthwhile. Eg, I think perhaps a modification of https://www.google.com/fonts/specimen/Abril+Fatface (or some other display text boldface) could work well. But equally I'm happy to use Kourosh's design, too.

So now that the Arabic is wrapping up, it would be good to get this underway. 

Kourosh, is the latest Latin committed to git and pushed to Github? I believe you were going to work on it further with what you've learned recently, and to use Glyphs 2. Let us know where we can evaluate the latest version and compare to the other options :) 

yes it is the last committed :) i have some idea, I’m working on it. :)

Cheers,
Dave

[Dave Crossland]

On 16 May 2015 at 05:20, K-B-STUDIO <taro...@gmail.com> wrote:

Kourosh, is the latest Latin committed to git and pushed to Github? I believe you were going to work on it further with what you've learned recently, and to use Glyphs 2. Let us know where we can evaluate the latest version and compare to the other options :) 

yes it is the last committed :) i have some idea, I’m working on it. :)

So its here, https://github.com/Tarobish/Jomhuria/blob/master/generated/documents/hello-world.pdf

Eben, what do you think? :) 

[Dave Crossland]

Hi

On 26 May 2015 at 11:01, K-B-STUDIO <taro...@gmail.com> wrote:

Last week, Lasse and I had a discussion about the next step. our current version it is a clean and works perfect. we are just working on the Anchor’s position (Tashkil Below Base), also more adjustment for spacing. we decided to have some stylistic set (just different shapes for some letterforms)

That sounds great! Can you start to gather native reader feedback from your contacts in the Persian design community - on behance, etc?

 

we talked to support Arabic supplement but we are not sure. any thoughts?

Khaled explained to me that these are legacy Unicode characters for glyphs that are today formed via OpenType shaping, so if you could post the specific Unicodes you are considering that would be good to better understand the issue :)

Cheers,
Dave

[K-B-STUDIO]

Hi everyone, here the latest:

Last week, Lasse and I had a discussion about the next step. our current version it is a clean and works perfect. we are just working on the Anchor’s position (Tashkil Below Base), also more adjustment for spacing. we decided to have some stylistic set (just different shapes for some letterforms)

we talked to support Arabic supplement but we are not sure. any thoughts?

Best
Kourosh

[K-B-STUDIO]

On May 26, 2015, at 1:11 AM, Dave Crossland <dcros...@google.com> wrote:

Hi

On 26 May 2015 at 11:01, K-B-STUDIO <taro...@gmail.com> wrote:

Last week, Lasse and I had a discussion about the next step. our current version it is a clean and works perfect. we are just working on the Anchor’s position (Tashkil Below Base), also more adjustment for spacing. we decided to have some stylistic set (just different shapes for some letterforms)

That sounds great! Can you start to gather native reader feedback from your contacts in the Persian design community - on behance, etc?

Thats a great idea, i just designed a poster with Jomhuria (included 28 lines with Title) i'm gonna ask for their feedback :)

 

we talked to support Arabic supplement but we are not sure. any thoughts?

Khaled explained to me that these are legacy Unicode characters for glyphs that are today formed via OpenType shaping, so if you could post the specific Unicodes you are considering that would be good to better understand the issue :)

Great, Yes i can do that, we just realized that we need to add in like 20 extra glyphs (we already have some of them).

here is the Unicodes:

uni0604

uni06c2.fina

uni08a6 / uni08a6.fina / uni08a6.init / uni08a6.medi

uni08ac / uni08ac.fina 

uni08aa

uni08AA.fina

uni08a7 / uni08a7.fina / uni08a7.init / uni08a7.medi

ni08a5 / uni08a5.fina / uni08a5.init / uni08a5.medi

uni08a4 / uni08a4.fina / uni08a4.init / uni08a4.medi

uni08a3 / uni08a3.fina / uni08a3.init / uni08a3.medi

uni08a9 / uni08a9.fina / uni08a9.init / uni08a9.medi

uni08a8 / uni08a8.fina / uni08a8.init / uni08a8.medi

uni08ab / uni08ab.fina 

uni08a2 / uni08a2.fina / uni08a2.init / uni08a2.medi

uni08a0 / uni08a0.fina / uni08a0.init / uni08a0.medi

uni077d / uni077d.fina / uni077d.init / uni077d.medi

uni077c / uni077c.fina / uni077c.init / uni077c.medi 

uni077b.init / uni077b.medi  

uni0779 / uni0779.fina

uni0777 / uni0777.fina / uni0777.init / uni0777.medi

uni0776 / uni0776.fina / uni0776.init / uni0776.medi

uni06c.init / uni06c.medi

unifdfb

Cheers,
Dave

[Dave Crossland]

Thanks!

Khaled, what do you think? :) 

[Eben Sorkin]

This is a good first import. The spacing needs quite a bit of work and there are some details in the design that may be worth revising such as the weight and position of the dot over the i & j, the very dark middle of the w, the very dark d & u, the width of the bottom of the t ( longer would be better), the odd shape of the k ( top too wide bottom not wide enough ) and so on.

It would be good to see some mixed settings as well to see how the scripts mate to each other.

Kourosh, do you know what do from here or do you need help?

-e.

 

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To post to this group, send email to googlefon...@googlegroups.com.
Visit this group at http://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAEozd0wUEE4m6soVdPn%2Bc2ky-wjaW_UmJyfgNw24SVp%2BZrdvXg%40mail.gmail.com.

[Khaled Hosny]

These are fine, the deprecated blocks are Arabic Presentation Forms-A[1]
and B[2] (with the exception of U+FDFA, U+FDFB and may be U+FDFC as
well).

Regards,
Khaled

1. http://unicode.org/charts/PDF/UFB50.pdf
2. http://unicode.org/charts/PDF/UFE70.pdf

[Dave Crossland]

Hi 

Okay cool, thank you Khaled :)

Lasse and Kourosh, what are the steps from here to shipping the Latin + Arabic font?

At the beginning of the project, Lasse outlined a 'main loop' of work:

- Are any glyphs missing?

- How are overshoots and kerning performing?

- How is GPOS and mark to mark performing?

- How is GSUB performing?

- How is the design of the latin and arabic (e.g., harmonize the designs)?

- Do we need more test documents?

What's the current state of these questions? :)

From this thread's last 3 weeks, I see these tasks mentioned:

- improve anchor positions (e.g. Tashkil Below Base)

- spacing improvements (some)

- add stylistic set glyphs (some)

- increase unicode coverage (67 glyphs)

- gathering type designer and native reader feedback

- reviewing the latin

I see that there's some movement on these items from https://github.com/Tarobish/Jomhuria/commits/master :)

I have these 'quantifying' questions:

- Kourosh, how did you create kerning classes in the end?

- how much anchor positioning is done, to do, total?

- how much spacing is done, to do, total?

- how many stylistic set glyphs are drawn, to do, total?

For the Latin, I think we are running out of time for Kourosh to work on the Latin with consultancy, so I recommend Lasse subcontract Eben to work on the Latin directly for the next 2-3 weeks to get it in a shippable state. Maybe Eben can do some Hangouts on Air with you both? Meanwhile the above Arabic tasks can be completed. 

And, to wrap up the project, the reviews:

- who will we ask to review the font?

- when reviewing the font, what questions will we ask of the test documents?

  - overall impressions, unprompted comments

  - do you like the font? would you use it?

  - if yes, what kinds of documents would you use it in?

  - if no, what specifically makes you dislike it?

  - how does the latin relate to the arabic?

  - what would you like to see improved/changed in future?

Cheers

Dave

[Lasse Fister]

On 31.05.2015 16:53, Dave Crossland wrote:
>
> Hi

Thank you Dave for this mail, I think it will helps us structuring the
end of the Project.

>
> Okay cool, thank you Khaled :)

Yes, thanks Khaled. I'm planning to set up some HTML based testing
pages. I think I will look into the Unicode Blocks you suggest to remove
and also generate tests for them. I don't just want to remove the glyphs
and prefer some ordered/controlled approach, where we can see what happens.

>
> Lasse and Kourosh, what are the steps from here to shipping the Latin
> + Arabic font?
>
> At the beginning of the project, Lasse outlined a 'main loop' of work:
>
> - Are any glyphs missing?

Kourosh suggested in his last mail to the list glyphs he likes to add.

>
> - How are overshoots and kerning performing?

I can't judge. Kourosh? Native Readers?

>
> - How is GPOS and mark to mark performing?

The legacy of amiri is that we don't really do mark to mark right now.
This is connected to the old-school unicode blocks, as far as I
understand. So maybe removing them is not a good option right now.

>
> - How is GSUB performing?

I think that is OK

>
> - How is the design of the latin and arabic (e.g., harmonize the designs)?

Latin needs work.

>
> - Do we need more test documents?
>

Yes, I will set up some test generation this week. Also I will create
HTML based documents.

>
> For the Latin, I think we are running out of time for Kourosh to work
> on the Latin with consultancy, so I recommend Lasse subcontract Eben
> to work on the Latin directly for the next 2-3 weeks to get it in a
> shippable state. Maybe Eben can do some Hangouts on Air with you both?
> Meanwhile the above Arabic tasks can be completed.

I agree, this can greatly speed up the task.

> And, to wrap up the project, the reviews:
>
> - who will we ask to review the font?
>
> - when reviewing the font, what questions will we ask of the test
> documents?
>
> - overall impressions, unprompted comments
>
> - do you like the font? would you use it?
>
> - if yes, what kinds of documents would you use it in?
>
> - if no, what specifically makes you dislike it?
>
> - how does the latin relate to the arabic?
>
> - what would you like to see improved/changed in future?
>

- did you spot any "bugs" in the documents (used glyphs, kerning, spacing)?


Also, I just pushed fonts and PDFs to github contaning the latest
changes of Kourosh.

L.

[Dave Crossland]

On 1 June 2015 at 13:59, Lasse Fister <la...@graphicore.de> wrote:

> - Are any glyphs missing?
Kourosh suggested in his last mail to the list glyphs he likes to add.

Are those needed for language support, or are they stylistic?

[Lasse Fister]

I can provide some unicode research:

On 26 May 2015 at 11:54, K-B-STUDIO <taro...@gmail.com> wrote:

Arabic 0600–06FF
http://www.unicode.org/charts/PDF/U0600.pdf

uni0604

"ARABIC SIGN SAMVAT
used for writing Samvat era dates in Urdu"

uni06c2.fina

"ARABIC LETTER HEH GOAL WITH HAMZA ABOVE
Urdu
actually a ligature, not an independent letter"

Well it doesn't encode a final form there, but it never does in  the normal Arabic range.


Arabic Extended-A 08A0–08FF
http://www.unicode.org/charts/PDF/U08A0.pdf

uni08a6 / uni08a6.fina / uni08a6.init / uni08a6.medi

uni08ac / uni08ac.fina 

uni08aa

uni08AA.fina

uni08a7 / uni08a7.fina / uni08a7.init / uni08a7.medi

ni08a5 / uni08a5.fina / uni08a5.init / uni08a5.medi

uni08a4 / uni08a4.fina / uni08a4.init / uni08a4.medi

uni08a3 / uni08a3.fina / uni08a3.init / uni08a3.medi

uni08a9 / uni08a9.fina / uni08a9.init / uni08a9.medi

uni08a8 / uni08a8.fina / uni08a8.init / uni08a8.medi

uni08ab / uni08ab.fina 

uni08a2 / uni08a2.fina / uni08a2.init / uni08a2.medi

uni08a0 / uni08a0.fina / uni08a0.init / uni08a0.medi

08A0 to 08A9 define "Extended Arabic letters for African languages"

08AA to 08AC define "Dependent consonants for Rohingya"

Already in the font are "Extended vowel signs for Rohingya" (08E4 to 08E9)
and "Tone marks for Rohingya" (08EA to 08EF). Also, glyphs for

uni08a0 / uni08a0.fina / uni08a0.init / uni08a0.medi

are also already in the font. So this looks like it adds  all necessary for Rohingya.


Arabic Supplement 0750–077F
http://www.unicode.org/charts/PDF/U0750.pdf

These are "Additions for Burushaski"

uni077d / uni077d.fina / uni077d.init / uni077d.medi
uni077c / uni077c.fina / uni077c.init / uni077c.medi
uni077b.init / uni077b.medi 
uni0779 / uni0779.fina
uni0777 / uni0777.fina / uni0777.init / uni0777.medi
uni0776 / uni0776.fina / uni0776.init / uni0776.medi

I found glyphs in Jomhuria for

uni077d* uni077c* uni0779* uni0777* uni0776*

uni077b.init / uni077b.medi  are not yet in Jomhuria.

Kourosh do the existing glyphs need a changed design?

uni06c.init / uni06c.medi

This is no unicode, it must be 4 charachters long. What is missing?


Arabic Presentation Forms-A FB50–FDFF
http://www.unicode.org/charts/PDF/UFB50.pdf

unifdfb

ARABIC LIGATURE JALLAJALALOUHOU

The surrounding "Word ligatures" are all there.

[taro...@gmail.com]

Hi list,
Just a few note
We still have some complications on:
1. kerning
2. Some adjustment for the marks above the baseline (browser it will be done in 2 days)
3. Lasse is working on some interference between characters and positions of the dots. Unlike any other Arabic fonts, we didn't change the position of the dots and since it's really common fir designer in Arabic font design to push the position of dots into the right side so it won't interference with the next character like بإ (as you see the position of 'dot' just moved to the right side so it's far from 'hamzeh' (below letter 'Alef') so, in the first step we recognized all the errors below the baseline (between dots, marks and characters) in the second step, Lasse will write script to add a small extinction between these characters. After all, we will have the same process for the errors above the baseline.
The reason that we decided to do this for the first time was:
1. Position of the dots is one of the most important part for the beauty and aesthetic in the Arabic script, when we change the position, it will cause some problem like readability; specially 'jumhuria' it's a headline font (means in the large size we clearly will see the position of dots it's wrong)
4. I personally prefer to go with 'Kourosh beigpour' as my name (nobody knows me as a Mehdi :) ) if you think it's possible since Mehdi it's only my passport name.
5. Is it common to post the first version on the Google font with some errors? If so that means this will be the first version and moving forward will have version 2, 3,etc.
And for the rest, we will just solve the problems and improve everything, Right?

Please let me know

Sent from my iPhone

[Dave Crossland]

On 1 June 2015 at 21:46, <taro...@gmail.com> wrote:

1. kerning

How many problems? Let's quantify the size of the problem so we can measure progress :)

 

2. Some adjustment for the marks above the baseline (browser it will be done in 2 days)

Sounds good

 

3. Lasse is working on some interference between characters and positions of the dots. Unlike any other Arabic fonts, we didn't change the position of the dots and since it's really common fir designer in Arabic font design to push the position of dots into the right side so it won't  interference with the next character like بإ (as you see the position of 'dot' just moved to the right side so it's far from 'hamzeh' (below letter 'Alef') so, in the first step we recognized all the errors below the baseline (between dots, marks and characters) in the second step, Lasse will write script to add a small extinction between these characters. After all, we will have the same process for the errors above the baseline.

The reason that we decided to do this for the first time was: Position of the dots is one of the most important part for the beauty and aesthetic in the Arabic script, when we change the position, it will cause some problem like readability; specially 'jumhuria' it's a headline font (means in the large size we clearly will see the position of dots it's wrong)

Again, how can you quantify this? :)

 

4. I personally prefer to go with 'Kourosh beigpour' as my name (nobody knows me as a Mehdi :) ) if you think it's possible since Mehdi it's only my passport name.

I think its fine to use Kourosh Beigpour, as long as the contact info is there, that's the main thing

 

5. Is it common to post the first version on the Google font with some errors? If so that means this will be the first version and moving forward will have version 2, 3,etc.

If the errors prevent the font from being useful, then we should hold back the font from publication. If the errors are less and the font is useful for at least 1 language, I'm happy to publish it and update it going forwards

 

And for the rest, we will just solve the problems and improve everything,  Right?

We need to quantify what the 'final' delivery state for this round of development is, and measure the progress from here to there. This round of development can't continue forever, and while there is always more to do, we need to wrap this up and move on to the next project :)

--

Cheers
Dave

[Kevin Donnelly]

(Although this is not directly relevant to Jomhuria at this stage, Dave has asked me to post it here for reference.  Sorry if it seems a bit "random".)

The development of Jomhuria is very interesting.  I think the font looks really nice, but perhaps too "chunky" for running text - if, as planned, it were to be used for headings and suchlike, I think it would look good.

Unfortunately I have no graphics skills to deal with the font design itself, but it may be worth making a wider point in relation to using Arabic script for other languages than the ones envisaged for Jomhuria.

The thing that jumped out at me from the discussion above is the desire to cut down on the number of glyphs in the font.  In effect, this will constrain its use to Arabic, Persian and Urdu.  I would argue that with very little extra effort, it could be extended for use with other languages that use/have used the Arabic script, and there is a considerable number of these: http://en.wikipedia.org/wiki/Arabic_script.  The main requirement is to include the glyphs listed there under "Special letters" (but these are not necessarily the only ones that might need to be added - see below).  In itself, this is not difficult: provided there is a UTF slot for the glyph, many of them are merely combinations of shapes and dots that are already used elsewhere in the abjad - see my howto for "p" at http://designwithfontforge.com/en-US/Adding_Glyphs_to_an_Arabic_Font.html.

When working on Andika!, I looked at all the Arabic fonts I could find, and ALL of them except for 4 (SIL's Scheherazade, Khaled's Amiri, Google's Droid Naskh, and a set of fonts from the PakType pr0ject) are worthless for writing Swahili (and presumably most other Arabic-script languages), because they contain only Arabic-language glyphs.

Just to expand a bit on this (ignore this paragraph if I'm teaching Granny to suck eggs): the writing system of any language is best adapted for writing that language, so Arabic writes Arabic best, and Roman writes Latin best (to simplify).  But it is possible to use ANY writing system to write ANY language, provided you add glyphs to represent the sounds of that new language.  So Roman script now has additions like "ł", "ö", "cz", etc to represent sounds occurring in other languages that were not originally in Latin, and the same thing happened with Arabic script - the difference is that this process was less formalised with Arabic script, because in most of the areas in which it was used, there was not necessarily what we would now consider a "nation-state" laying down a "standard" orthography, and many of these areas were later subjected to colonialism by the imperial powers, who usually (for reasons that included political and religious ones as well as linguistic and pedagogical ones) mandated that those languages should be written in a (suitably adapted) version of Roman script.

There is an impression that Arabic script is ill-suited to writing other languages (because it only distinguishes three vowels, because it normally only writes consonants, etc), but nothing could be further from the truth, as even a brief perusal of texts in non-Arabic languages will show (for Africa, a relevant text is "The Arabic Script in Africa: Studies in the Use of a Writing System", edited by Meikal Mumin and 
Kees Versteegh, Brill, Leiden, 2014).  Writers in non-Arabic languages showed considerable ingenuity in adapting it to those languages, though as I noted above the process was uneven.

An example of this is in the attachment p5jaafari_stacked.pdf. A couple of years ago I started developing a set of tools (called Andika!, "write!") to write Swahili in Arabic script - http://kevindonnelly.org.uk/swahili.  The p5 pdf is a page from the project I actually started developing Andika! for, the creation of an edition of a Swahili ballad from two Arabic-script manuscripts.  Virtually all classical Swahili poetry has been published in Roman transcription, and apart from losing something of the character of the original, you can never quite be sure what the editor has added to or omitted from the original to get the final published text.  So I really wanted to include the Arabic original, transcribed letter-for-letter from the MSs.  (There are also a host of additional benefits to providing a digital version of the original MS text, eg creating concordances, comparing different ways of writing the same word, etc.)

In the p5 pdf, one MS is in green, and the other is in blue.  The tier below the Arabic script give a close transcription of it in Roman (going right-to-left like the Arabic script), and the tier below that gives a version (going left-to-right) that approximates much more closely to "standard" Roman-script Swahili.  Both of these are automatically generated from the Arabic script, and then further edited manually as required.  The tier below that is a translation.  If you look at the green and blue transcriptions, you can see that the blue one is less well-adapted to Swahili than the green one (it may be a copy of an older MS) - it uses only 3 vowels (Swahili has 5), does not mark labialisation (eg it has "t" instead of "tw" in "kitwa", 'head'), and often does not mark prenasalisation (eg it has "gh" instead of "ng" - no examples in this extract).  However, it does distinguish between dental "d" (dal, U062F) and alveolar "d", though it uses "r" (reh, U0631) to write the latter (though "r" is also used to write "r" proper).  So in 16b, you get "akanenda" in the green MS, but "akinira" in the blue one (the second vowel is just a difference in tense).

The point is that in most Arabic fonts, you cannot write this word as anything other than something like "akininda", because a glyph for "e" (a subscript alef - U0656 - is used by the writer of the green MS) is missing.  In effect, you need to be able to speak the language before you write it, and the script becomes just an aide-memoire rather than a transcription - both of these points make it difficult to use the script pedagogically.  On the East African coast, the places still using it (usually mosque schools) get around this by writing out the text neatly by hand, and then photocopying that.

As it stands, Jomhuria will not be useable for Swahili or most other Arabic-script languages, because it will not include important glyphs (the list in Table 4.2 of the Andika! manual).  [At least, that is my impression - I couldn't install the ttf file from the Github repo on Kubuntu 14.04 because it said the ttf file was not a font.] I would say that the font could be made far more useful if these glyphs were included.

There have been attempts to "standardise" Arabic script for African languages.  ISESCO attempted this some 20 years back, and the second attachment (isesco.pdf) gives an example of this in Appendix B (the preface from a book of Islamic prayers - a transliteration into Roman script is at App F).  This output was originally produced by a special typewriter, but the later iterations used a computer.  I'm trying to find out more about this, its standing, its current state, etc, but it may be that the quality of the output could be improved if recent technical developments could be applied to it.  Apps D-F give the same text in Scheherazade, Amiri and Droid Naskh respectively.  All, in my view, look an order of magnitude better than App B, but the one that comes out best (in my view) is Scheherazade.  Amiri puts all the diacritics on the same line above the consonants (Khaled told me this was due to issues with the ligatures, I think), which makes them seem (to my Western eyes) somewhat detached from the consonants.  Droid Naskh seems to have difficulties with displaying some of the descenders.  I haven't tested the PakType ones here.  The main point, though, is that only this group of fonts can make any attempt at representing Swahili in Arabic script, so the question really comes down to: should Jomhuriya be added at some point to this group or not?

(Having said that, even these fonts are missing some glyphs, mostly because those glyphs are not yet in the Unicode standard.  The angled subscript for "e" is one, and a "damma with tail" used by some Swahili writers to stand for "o" is another.)

[Dave Crossland]

Thanks for this Kevin! Currently the language support is only scoped to Arabic, Persian and perhaps Urdu, but I'm very happy to see you on this list and when we get to Africa this will all be invaluable :) 

[Dave Crossland]

Hi Adam (and Khaled!)

Thanks for your detailed thoughts on this. I suggested SILE because Khaled has been contributing recently. Khaled, I'm curious to better understand your motivation to use and contribute to SILE?

Cheers

Dave

--

Cheers
Dave

[Dave Crossland]

On 1 June 2015 at 21:46, <taro...@gmail.com> wrote:

We still have some complications on:
1. kerning
2. Some adjustment for the marks above the baseline (browser it will be done in 2 days)
3. Lasse is working on some interference between characters and positions of the dots.

What's the latest?

[Khaled Hosny]

It has proper bidirectional support for one (something that *TeX is
unlikely to ever get) and hacking Lua is ordered of magnitude easier
than hacking Knuths WEB code (either the original Pascal in XeTeX or the
C translation in LuaTeX). It is rather funny that Adam is concerned
about Lua when TeX is written in a dialect of Pascal and using a system
only Knuth ever used in any substantial way (XeTeX makes it even worse
with having parts written in C and C++ with very non obvious ways to
interact between them).

The comments about the show-off file or the manual are rather snarky,
may be a professional book designer is needed to give a nice looking
design, but that says nothing bad about the capabilities of the system.
The comment about the website is even more snarkier and uncalled-for.

Regards,
Khaled

[Lasse Fister]

Sorry, I'm answering a bit late, I was sucked up into a fight with OpenType features and such.

In order to enable Eben to help us on the Latin design, I made a UFO out of the Latin sfdir file (using fontforge). I pushed the ufo to github. The round trippping test before I pushed went well, I think I'm going to switch to the UFO as a primary source of the latin-font for the build process in the future.

Maybe we can switch the Arabic (main-file) to UFO, too, but that will not be so straight forward. The reasoning for this would be to enable other kerning tools for Kourosh (what he will need anyways).

Also, I started to use the bugtracker of the github repository to keep an overview of what needs to be done:
https://github.com/Tarobish/Jomhuria/issues

At the moment, I'm on the task to prepare OpenType features for Jomhuria, that are preventing collisions between some glyph combinations (when there are marks present).
I wrote a neat decomposing Lookup (Type 2 Multiple substitution) That inserts a Kashida (streching glyph) between the critical combinations, took me two approaches to find the current solution.
The harder task however is to create useful feedback for this kind of work. So for visual feedback I'm writing JavaScript that generates the intended character combinations. I'm looking at this in the Browser (FF and Chrome) And for debugging and more detailed information, I'm using Harfbuzz directly, which gives me the real shaping information, which glyphs are used for a ceratain input.
It's still hard sometimes to figure out what is going on :-)
This is all happening in another branch, because it may leave the font in a broken state while I'm working on it. https://github.com/Tarobish/Jomhuria/tree/html-docs-and-collisions
I'm dropping more details about this into here: https://github.com/Tarobish/Jomhuria/issues/6

Last week I also did some massage to the ttf file created by our build process using Fonttools. There are some tables and entries to be removed automatically, some entries could be made from within Fontforge.
Dave also asked me to set ascender and descender to the global yMin yMax values, But I think the default line-spacing is extreme big now. This is because we have some very extreme characters in the font that push the max-values up; like unicode 06DD ARABIC END OF AYAH. I guess I will get feedback about the line heights again, from somewhere. This was in https://github.com/Tarobish/Jomhuria/issues/3

L.


It's located here:
https://github.com/Tarobish/Jomhuria/tree/master/sources/jomhuria-latin.ufo

[Khaled Hosny]

On Thu, Jun 11, 2015 at 04:39:13PM +0200, Lasse Fister wrote:
> Dave also asked me to set ascender and descender to the global yMin yMax
> values, But I think the default line-spacing is extreme big now. This is
> because we have some very extreme characters in the font that push the
> max-values up; like unicode 06DD ARABIC END OF AYAH.

Right, that practice does not work well for Arabic. What you should do
is to set typo and hhea metrics to sensible values that give the line
spacing you desire, and set win metrics to the max (just ticking the
offset check mark in FontForge and using 0 as value will do), and just
ignore apps that still use win metrics for line spacing because they are
unfixable anyway.

Regards,
Khaled

[Lasse Fister]

Thanks Kevin,

this is very good information :-)

On 06/01/2015 06:58 PM, Kevin Donnelly wrote:

The thing that jumped out at me from the discussion above is the desire to cut down on the number of glyphs in the font.  In effect, this will constrain its use to Arabic, Persian and Urdu.  I would argue that with very little extra effort, it could be extended for use with other languages that use/have used the Arabic script, and there is a considerable number of these: http://en.wikipedia.org/wiki/Arabic_script.

Actually, we are reducing letters that we don't need because Jomhuria has a much simpler style than Amiri. Amiri, being our starting point, is much richer in details, so we inherited a lot of letter-variants that we don't need. We don't remove letters with a distinct use.

When working on Andika!, I looked at all the Arabic fonts I could find, and ALL of them except for 4 (SIL's Scheherazade, Khaled's Amiri, Google's Droid Naskh, and a set of fonts from the PakType pr0ject) are worthless for writing Swahili (and presumably most other Arabic-script languages), because they contain only Arabic-language glyphs.

I'm interested in finding out for which scripts Jomhuria is useful. But it seems to me that it's more complex than just checking unicode coverage (especially for Arabic). We'd need reliable test-documents for each script. The lack of good testing material for Arabic (and in general) is remarkable anyways. Maybe we should set up a project together with everybody interested – Libre Test Documents for type design and development. My main problem is that I can't read Arabic and that I can't write it either. I really can't judge it. However, I could support this with other skills.

As far as I understood http://testmyfont.com/ will help with such tasks. Dave?

As it stands, Jomhuria will not be useable for Swahili or most other Arabic-script languages, because it will not include important glyphs (the list in Table 4.2 of the Andika! manual).  [At least, that is my impression

I checked Table  4.2 an I believe we have all of them. Have a look here https://github.com/Tarobish/Jomhuria/blob/master/generated/documents/Jomhuria-Regular-table.pdf

- I couldn't install the ttf file from the Github repo on Kubuntu 14.04 because it said the ttf file was not a font.] I would say that the font could be made far more useful if these glyphs were included.

This is interesting, I don't have problems with Jomhuria in any tool that reads it in my workflow(Firefox, Chrome, Harfbuzz, FontTools/TTX, woff2_compress, etc.) But I don't use KDE either.

The main point, though, is that only this group of fonts can make any attempt at representing Swahili in Arabic script, so the question really comes down to: should Jomhuriya be added at some point to this group or not?

We can at least record issues with Swahili here: https://github.com/Tarobish/Jomhuria/issues It won't have a high piority in this round however.

(Having said that, even these fonts are missing some glyphs, mostly because those glyphs are not yet in the Unicode standard.  The angled subscript for "e" is one, and a "damma with tail" used by some Swahili writers to stand for "o" is another.)

So how are these glyphs entered?

L.

[Lasse Fister]

Hi all,

A quick update.

I created a gh-pages page to serve test-documents for Jomhuria.

http://tarobish.github.io/Jomhuria

The issue #6 is about collisions between glyphs below the baseline. I'm
using JavaScript to generate the test cases. So far the collisions are
solved, but in
http://tarobish.github.io/Jomhuria/#tests/collision-below-2 we can
whitness cases where some Marks are positioned badly, search for the
block of "Alef: uni0622.fina' for example.

I'm quite happy with having this infrastructure now in place, also I am
more confident in working with OpenType features and debugging of these.
So, I think next week a lot of progress should happen.

L.

[Dave Crossland]

Hi

On 11 June 2015 at 11:31, Lasse Fister <la...@graphicore.de> wrote:

On 06/01/2015 06:58 PM, Kevin Donnelly wrote:

When working on Andika!, I looked at all the Arabic fonts I could find, and ALL of them except for 4 (SIL's Scheherazade, Khaled's Amiri, Google's Droid Naskh, and a set of fonts from the PakType pr0ject) are worthless for writing Swahili (and presumably most other Arabic-script languages), because they contain only Arabic-language glyphs.

I'm interested in finding out for which scripts Jomhuria is useful. But it seems to me that it's more complex than just checking unicode coverage (especially for Arabic). We'd need reliable test-documents for each script. The lack of good testing material for Arabic (and in general) is remarkable anyways. Maybe we should set up a project together with everybody interested – Libre Test Documents for type design and development. My main problem is that I can't read Arabic and that I can't write it either. I really can't judge it. However, I could support this with other skills.

As far as I understood http://testmyfont.com/ will help with such tasks. Dave?

testmyfont.com is not currently useful for me; it trailed off mainly because I was unable to make time to bring the developer testing documents and set of questions for those documents. Therefore the testing functionality has been stubbed but not fully implemented. I would be very happy if you would start contributing to that project to make it useful for you. However, you may find upon reviewing it that the js code architecture is not what you would like, and you'll consider some ideas from it and put it to the side and continue on your own testing document system that you've already started. 

The current js code there is today entirely bootstrap and custom js, and in use I find it frustratingly slow. I also find the UI quite clunky, and have been pondering approaches to a redesign - https://github.com/metapolator/ddt/issues/87 

I also expect to announce a new project shortly, led by the University of Reading, related to https://speakerdeck.com/gerryleonidas/on-minimum-quality-in-typeface-design

- I couldn't install the ttf file from the Github repo on Kubuntu 14.04 because it said the ttf file was not a font.] I would say that the font could be made far more useful if these glyphs were included.

This is interesting, I don't have problems with Jomhuria in any tool that reads it in my workflow(Firefox, Chrome, Harfbuzz, FontTools/TTX, woff2_compress, etc.) But I don't use KDE either.

I'm also curious how you tried to install it :)

--

Cheers
Dave

[Khaled Hosny]

On Fri, Jun 12, 2015 at 11:38:35PM +0200, Lasse Fister wrote:
> Hi all,
>
> A quick update.
>
> I created a gh-pages page to serve test-documents for Jomhuria.
>
> http://tarobish.github.io/Jomhuria
>
> The issue #6 is about collisions between glyphs below the baseline. I'm
> using JavaScript to generate the test cases. So far the collisions are
> solved, but in
> http://tarobish.github.io/Jomhuria/#tests/collision-below-2 we can
> whitness cases where some Marks are positioned badly, search for the
> block of "Alef: uni0622.fina' for example.

Looks like the anchors are missing here, or not applied somehow.

BTW, don’t bother testing mark positioning with uniF* glyphs, and u1EE*
are math glyphs and you should just drop them from the font, they are of
no use for such a font.

Regards,
Khaled

[Dave Crossland]

On 12 June 2015 at 18:43, Khaled Hosny <khale...@eglug.org> wrote:

Looks like the anchors are missing here, or not applied somehow.

What's the latest Lasse?

[Kevin Donnelly]

Sorry for the delay in replying - still getting used to Groups, and I hadn't asked it to copy me summaries!

On Thursday, 11 June 2015 16:31:24 UTC+1, Lasse Fister wrote:

Actually, we are reducing letters that we don't need because Jomhuria has a much simpler style than Amiri. Amiri, being our starting point, is much richer in details, so we inherited a lot of letter-variants that we don't need. We don't remove letters with a distinct use.

Ah, my mistake.  I've managed to get it installed now on my laptop, and it does seem to cover everything - hooray!  I'm attaching an excerpt from a Swahili ballad with Jomhuria as the font.  It doesn't work so well as the main font (!), but the heading looks good.  The only thing I found on doing some typing was that there's a gap between kaf and lam if they're adjacent - see kl.png.

I'm interested in finding out for which scripts Jomhuria is useful. But it seems to me that it's more complex than just checking unicode coverage (especially for Arabic). We'd need reliable test-documents for each script. The lack of good testing material for Arabic (and in general) is remarkable anyways. Maybe we should set up a project together with everybody interested – Libre Test Documents for type design and development. My main problem is that I can't read Arabic and that I can't write it either. I really can't judge it. However, I could support this with other skills.

 This would be a good idea.  I can provide some Swahili stuff if that's any use.

(Having said that, even these fonts are missing some glyphs, mostly because those glyphs are not yet in the Unicode standard.  The angled subscript for "e" is one, and a "damma with tail" used by some Swahili writers to stand for "o" is another.)

So how are these glyphs entered?

They can't be, if the font doesn't include them ...

[Lasse Fister]

On 06/23/2015 03:29 PM, Kevin Donnelly wrote:

On Thursday, 11 June 2015 16:31:24 UTC+1, Lasse Fister wrote:

Actually, we are reducing letters that we don't need because Jomhuria has a much simpler style than Amiri. Amiri, being our starting point, is much richer in details, so we inherited a lot of letter-variants that we don't need. We don't remove letters with a distinct use.

Ah, my mistake.  I've managed to get it installed now on my laptop, and it does seem to cover everything - hooray!  I'm attaching an excerpt from a Swahili ballad with Jomhuria as the font.  It doesn't work so well as the main font (!), but the heading looks good.

Ah, cool. I see in the properties that you made the document with XeTeX. If you would send me the source document, I'd try to regenerate it every time we update the font.

The only thing I found on doing some typing was that there's a gap between kaf and lam if they're adjacent - see kl.png.

Thanks for reporting. We are already working on this: https://github.com/Tarobish/Jomhuria/issues/7

I'm interested in finding out for which scripts Jomhuria is useful. But it seems to me that it's more complex than just checking unicode coverage (especially for Arabic). We'd need reliable test-documents for each script. The lack of good testing material for Arabic (and in general) is remarkable anyways. Maybe we should set up a project together with everybody interested – Libre Test Documents for type design and development. My main problem is that I can't read Arabic and that I can't write it either. I really can't judge it. However, I could support this with other skills.

 This would be a good idea.  I can provide some Swahili stuff if that's any use.

Allright, I'm keeping that in my mind, in case I start this. Thanks again.

Lasse

[Lasse Fister]

Hi everybody,

here my status update.

We got now two issues about marks: https://github.com/Tarobish/Jomhuria/issues/19 and https://github.com/Tarobish/Jomhuria/issues/20
that's my job for today.

I closed all of the "colliding glyphs" issues, as they are solved now.

Kourosh is fixing the broken Kaf glyph in Kaf-Lam combinations.
https://github.com/Tarobish/Jomhuria/issues/7
I made two test tables for this:

http://tarobish.github.io/Jomhuria/#tests/kaf-lam-alf-1
http://tarobish.github.io/Jomhuria/#tests/kaf-lam-alf-2

Yesterday, I also had another round on the test-table generating code and created two new modules that all these tables share now:

TableData: this uses two or three axes (lists of glyphs, usually) which are used to generate all combinations between the axes. The actual cell content of the table is generated by an injected method, to keep it useful over a broad range of cases.

TableContent (I will change the name to TableController I think): This provides a drop-down menu to add comparision rows or columns to the table. I currently use only Amiri-Bold in the comparisons, but will probably add a dropdown to change the font used.

I added a (very) small (not complete) parser to extract glyph classes from fea files. That way I can use the classes defined in our "classes.fea" file directly to generate test tables. (All served by gh-pages, btw)

I think the comparison thing is powerful. We can use it to find even more flaws. Here's a screenshot:

My Goal is to solve all the engineering problems in the github issues ASAP. Either by doing it myself or by identifying what needs to be done by Kourosh, the designer. Then find a way that allows Kourosh to do kerning with the tool he prefers.

Also, we are trying to get the development of the Latin started (and subsequently done ;-) ) with Eben as a designer.
Eben, I like your input. We should talk about when this all happens, however.
As well as Kourosh: I think kerning the Arabic is the last big thing you need to do. What do you need to get started?
I'm really keen to get this thing done soon :-)

Here are some messages of Eben about the Latin:

@EbenSorkin https://github.com/Tarobish/Jomhuria/issues/16#issuecomment-113680757

I am finding that the Latin is pretty deeply flawed. The main idea is right in terms of weight and width but I think I probably want to get rid of the slab serifs and replace them with something more old style - or to go Sans. I also want to re-draw the rounds to echo the more sophisticated shapes in the Arabic. I am also very interested in working to echo the density of the Arabic which is very display oriented. At the moment the spacing is too loose to match well.

Anyway - if you would both give me some feedback about these ideas that would be great. I would like to know we are mostly in agreement before I begin. I will of course send you proofs of a limited glyph set early on so we can check that this approach is working together.

I guess we will have a hangout about this?

Here is another mail that did not find it's way to this forum:

On 06/15/2015 09:21 AM, Eben Sorkin wrote:

I started looking at the Latin just to be clear about what the issues will be before I formally submit documents to start.

Some comments:

I see very divergent Typo, hhea and Win ascender and descender values. I would standardize on one set and keep the zero line gap you have.

We import the Latin into the Arabic, so the Arabic is defining this kind of data. If any value is bogus, we'll have to fix it there.

The UFO didn’t have the NULL, space and the .notdef glyphs. I suspect the spit was made so that the latin would not clash with the arabic and the arabic kept these. Still, I’ll need the space so I added it and made it match the 600 units you have. This seems wide for the latin in a display font for sure. Would you guys look and see if this needs to be this wide for the Arabic? To my eye it looks a bit wide there too.

We are now at 400. There is an issue for this (waiting to be closed): https://github.com/Tarobish/Jomhuria/issues/10

Even though the Arabic is quite systematized it does have very swooping asymmetric shapes in its rounds - like the lower case a. It seems like the Latin will need to share this quality in its other rounds to more effectively support and mix with the Arabic and in order to maintain the feeling seen in the Arabic. This will mean replacing those that lack the feature. This would be the rounds of b d p q and in the caps. Maybe the o too.

The slab serifs chosen don’t echo with the Arabic at all. A semi-triangular serif at x height in n r & so on that has more of the shape of the tooth of the Arabic seems like a match to me. I think a quiet stubby serif at baseline and at x height in k x w etc would work well to compliment that and minimize noise might be good or perhaps no serif at all in these places would be better. It may be that simply making the Latin a sans will match better. I propose making 2-3 limited glyphs set Latins to test with the Arabic in setting to see what actually fits best.

I'm looking forward talking about this.

I am not sure about the Arabic but in the Latin I am seeing some almost (but not quite) straight lines. I’ll fix these but look out for them in the rest of the design.

Should I try to write a script that searches for this?

In the diamond shapes I suggest using a short vertical or horizontal line at the sharp corners. This will help TTFA to give you a better rendering result on Freetype and windows based screens.

I like this. It's a Job for Kourosh, however.

I have been making changes to a branch of the project on Github. It may not be worth a pull just yet.

-e.

Lasse

[Kevin Donnelly]

On Tuesday, 23 June 2015 16:11:12 UTC+1, Lasse Fister wrote:

Ah, cool. I see in the properties that you made the document with XeTeX. If you would send me the source document, I'd try to regenerate it every time we update the font.

OK - attached.  I've tried to trim anything irrelevant out of it, and it compiles OK here.

[Dave Crossland]

On 23 June 2015 at 12:10, Lasse Fister <la...@graphicore.de> wrote:

Should I try to write a script that searches for this?

FontForge has one, so does https://github.com/typesupply/glyph-nanny I think

[Lasse Fister]

Thank you very much. I changed the font setup to use the fonts directly from a filesystem path.

It builds:

https://github.com/Tarobish/Jomhuria/blob/master/generated/documents/jaafari_jomhuria.pdf

L.

[Lasse Fister]

So far we are almost done with open engineering issues at github, as it
seems.

@Kourosh I think that maybe got lost in the big last message. I need to
plan with you how we are approaching the kerning of the Arabic part.

As far as I know, you want to use Glyphs for kerning, is that correct?
So probably I should prepare a UFO for you, that you can import into Glyphs.

Then you do the kerning -- but just a testing round for the start.

Then we need to get the kerning data out of glyphs. There are several
ways possible. The one I'd prefer most would be (if there is) a "Export
kerning feature as *.fea" option in Glyphs. Please check that.

Alternatively, you could export the Project as UFO and I'd see how to
generate the kerning feature from that.

To make sure everything works out: I ask you to first make a tiny test
round, then I see how I can get the kerning back into the project. If
all that works I tell it to you and then you can start doing the real thing.

L.

[Dave Crossland]

I am getting mixed results from informal reviews, so I hope we can step up the user testing. Kourosh, have you got a list of Persian designers to review it? :) 

[Lasse Fister]

On 06/24/2015 05:39 PM, Dave Crossland wrote:
> I am getting mixed results from informal reviews, so I hope we can
> step up the user testing.

How do we do this?

[Dave Crossland]

Get users to look at the PDF/web page and post their comments on this thread. 

If you wanted to be more sophisticated, you could add a little JS to the testing web page to allow users to select text, log the selection's parent id, or the selection's unicode string contents, and open a comment box, log their input, and then post the log to a remote storage backend as er https://unhosted.org/tools/ 

http://ajanthanm.github.io/hindiwebfont/web/ did this last year, using http://www.google.com/forms/about/ as a back end

[Lasse Fister]

I can do this. How was the experience with that? Is it worth the effort?

We could also spend a bit more time to make a few nicer-to-look-at
samples. I think the font should rather be judged in display/headline
context. I did not do much styling of the website as well.

[Dave Crossland]

I just chatted with Peter Sikking about user testing of the metapolator app, and he confirmed my experince that it is 'garbage in garbage out' with user testing; you need expert users who can give useful feedback. Asking just anyone to comment on fonts, you get a lot of comments that are not useful. 

Fortunately you are going to Granshan, and Eben and 100s of non-Latin type designers will be there :) 

[Kourosh Beigpour]

Sure, this is the plan. lets do some test to see how it works. 

I can do this tomorrow :) ill let you know

[Kourosh Beigpour]

I do have a list, all they want its a font to use it and see how it works. do you think, i should send them, the one we have or we have to wait until it will be done? (kerning) :) please let me know

[Dave Crossland]

On 25 June 2015 at 12:53, Kourosh Beigpour <taro...@gmail.com> wrote:

I do have a list, all they want its a font to use it and see how it works. do you think, i should send them, the one we have or we have to wait until it will be done? (kerning) :) please let me know

Yes. If they report kerning problems, we know they are being honest :) 

[Lasse Fister]

Hi List.

Kourosh, I applied the kerning from the UFO you sent me. Please check if your kerning is applied correctly.

Eben, sorry for my delayed answer.

When I go to: https://github.com/EbenSorkin/Jomhuria/tree/master

It says that your last change was 15 days ago. It looks like your changes did not make it to github. Or am I staring at the wrong repository?

Also, the ufo you sent me unfortunately makes all kinds of problems. You renamed some glyphs, that makes the features.fea file contained in the ufo outdated. Also, when I remove the features.fea file (then make an sfdir out of the ufo) and try to use our build script (which among other things merges the fonts) I get a serious error from (I think it's) sortsmill "Segmentation fault (core dumped)". I'll investigate this, of course. We can care for the features later, so what you can do is telling me where the current ufo is located.

The texts that we use to generate the PDFs are in:

https://github.com/Tarobish/Jomhuria/tree/master/document-sources

The pdfs are generated from the *.tex documents, but the original texts where the *.txt files and partly *.rtf files (if there are both rtf and txt files you should treat the txt files as the source.)

If you want to add texts to this you should also use txt file. I think I will then make one of those tex files from it, then we can generate pdfs.
For the website, we can also use text or markdown or html-content.

For some better representation on the website, we should maybe together decide for a plan how the font should be represented. I can then improve the design a bit, to not scare the people away. As I see it we have right now rather technical speciment on the page, to see if a specific bug is fixed etc. , we should add something that helps to verify the design. Ideas?

L.


On 06/30/2015 01:24 AM, Eben Sorkin wrote:

I have improved it further. Will you guys send me the text strings you have been testing with for the Arabic and the most current version of the Arabic font? Is it the one on git hub?

There is only the merged final font: https://github.com/Tarobish/Jomhuria/tree/master/generated
maybe you can use yours and then that one as a fallback. If I can get your work into the build process I can update the the file.
If you want to build it yourself we need to talk about using docker.

I want to try to nail down the correct color and density next.

Sent from Outlook

sounds good

On Mon, Jun 29, 2015 at 12:18 PM -0700, "Kourosh Beigpour" <taro...@gmail.com> wrote:

Hi Eben!
Many thanks, love it :) looks great
> On Jun 29, 2015, at 2:45 AM, Eben Sorkin  wrote:
> 
> Here is a copy if that is simpler for either of you.
> 
> 
> 
> -e.
> 

[Eben Sorkin]

On Jun 30, 2015, at 11:47 AM, Lasse Fister <la...@graphicore.de> wrote:

Hi List.

Kourosh, I applied the kerning from the UFO you sent me. Please check if your kerning is applied correctly.

Eben, sorry for my delayed answer.

When I go to: https://github.com/EbenSorkin/Jomhuria/tree/master

It says that your last change was 15 days ago. It looks like your changes did not make it to github. Or am I staring at the wrong repository?

It must not be the right one somehow. I’ll work to figure out what’s going on today.

Also, the ufo you sent me unfortunately makes all kinds of problems. You renamed some glyphs, that makes the features.fea file contained in the ufo outdated.

Maybe I can fix that .fea file? Some of the glyph remming is there because the it is more compatible/standard in the new way. Scommaacent for instance needs to be a unicode name to avoid some conflicts.

Also, when I remove the features.fea file (then make an sfdir out of the ufo) and try to use our build script (which among other things merges the fonts) I get a serious error from (I think it's) sortsmill "Segmentation fault (core dumped)". I'll investigate this, of course. We can care for the features later, so what you can do is telling me where the current ufo is located.

It sounds like maybe this is just to do with the .fea file not matching glyph names. Do you think that’s correct?

The texts that we use to generate the PDFs are in:

https://github.com/Tarobish/Jomhuria/tree/master/document-sources

Hooray!

The pdfs are generated from the *.tex documents, but the original texts where the *.txt files and partly *.rtf files (if there are both rtf and txt files you should treat the txt files as the source.)

If you want to add texts to this you should also use txt file. I think I will then make one of those tex files from it, then we can generate pdfs.
For the website, we can also use text or markdown or html-content.

Cool!

For some better representation on the website, we should maybe together decide for a plan how the font should be represented. I can then improve the design a bit, to not scare the people away. As I see it we have right now rather technical speciment on the page, to see if a specific bug is fixed etc. , we should add something that helps to verify the design. Ideas?

We might want to show the font in use which we anticipate as likely/appropriate. i am guessing book covers, magazines, food or other packaging. Places where style is a big deal. This is not going to be the sort of thing that would be used for signs or long text. - Kourosh what do you think?  

-e.

 

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To post to this group, send email to googlefon...@googlegroups.com.
Visit this group at http://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/5592BA2B.7050506%40graphicore.de.

For more options, visit https://groups.google.com/d/optout.

<0xF067AF71.asc>

[Dave Crossland]

On 30 June 2015 at 13:54, Eben Sorkin <sorki...@gmail.com> wrote:

Scommaacent for instance needs to be a unicode name to avoid some conflicts.

The FDK has a GlyphOrderAndAliasDB file that allows you to conveniently use 'human' names when working and unicode-related names in the production files. 

Does the SortsMill workflow allow for this?

[Lasse Fister]

On 06/30/2015 07:54 PM, Eben Sorkin wrote:

On Jun 30, 2015, at 11:47 AM, Lasse Fister <la...@graphicore.de> wrote:

Hi List.

Kourosh, I applied the kerning from the UFO you sent me. Please check if your kerning is applied correctly.

Kourosh answered

On 06/30/2015 07:10 PM, Kourosh Beigpour wrote:

> It seems something went wrong (we have the kerning here but in the wrong side)
> Please let me know, if i did it in the wrong way
> Please compare the pictures, that's what i can see in Glyphapp (the kerning looks right) but in our generated document it doesn't

So that may be a problem with either: Glyphs, ufo2fdk or Sortsmill :-/ I'll also try to solve this one. Maybe some LTR/RTL confusion in one of these softwares.

Eben, sorry for my delayed answer.

When I go to: https://github.com/EbenSorkin/Jomhuria/tree/master

It says that your last change was 15 days ago. It looks like your changes did not make it to github. Or am I staring at the wrong repository?

It must not be the right one somehow. I’ll work to figure out what’s going on today.

Also, the ufo you sent me unfortunately makes all kinds of problems. You renamed some glyphs, that makes the features.fea file contained in the ufo outdated.

Maybe I can fix that .fea file?

There are glyph names used all over the place. In built.py, I think I have to adopt that, too. My last attempt skips missing glyphs gracefully. There are also other fea-files in the project that refer glyphs from the latin, I skipped them in the last successful test/build.

Some of the glyph remming is there because the it is more compatible/standard in the new way. Scommaacent for instance needs to be a unicode name to avoid some conflicts.

Hm, we inherited the glyph names. You basically say that also Amiri is broken in hindsight to these conflicts? Is there a good source for problems related to this? What breaks when certain glyphs have the wrong name (that is not our build)?

Also, when I remove the features.fea file (then make an sfdir out of the ufo) and try to use our build script (which among other things merges the fonts) I get a serious error from (I think it's) sortsmill "Segmentation fault (core dumped)". I'll investigate this, of course. We can care for the features later, so what you can do is telling me where the current ufo is located.

It sounds like maybe this is just to do with the .fea file not matching glyph names. Do you think that’s correct?

It's mixed things. The core dump goes away when I don't use a fontforge produced sfdir with sortsmill and instead import the ufo directly (without features.fea).
Then I had to catch and skip some errors because of the missing glyphs. And I had to skip some feature files. I think I'll have to evaluate what all this stuff is supposed to do.

I was initially using fontforge to import the ufo as sfdir, because the fontforge support of ufo should be more up to date than Sortsmill, afaik. However, it seems that now fontforge-sfdir is less compatible to Sortsmill than ufo. I'm seriously thinking about changing the whole build process to something more robust , but I'm not sure yet.

For some better representation on the website, we should maybe together decide for a plan how the font should be represented. I can then improve the design a bit, to not scare the people away. As I see it we have right now rather technical speciment on the page, to see if a specific bug is fixed etc. , we should add something that helps to verify the design. Ideas?

We might want to show the font in use which we anticipate as likely/appropriate. i am guessing book covers, magazines, food or other packaging. Places where style is a big deal. This is not going to be the sort of thing that would be used for signs or long text. - Kourosh what do you think?  

I agree

[K-B-STUDIO]

On Jun 30, 2015, at 8:47 AM, Lasse Fister <la...@graphicore.de> wrote:

Hi List.

Hi

Kourosh, I applied the kerning from the UFO you sent me. Please check if your kerning is applied correctly.

It seems something went wrong (we have the kerning here but in the wrong side)

Please let me know, if i did it in the wrong way

Please compare the pictures, that's what i can see in Glyphapp (the kerning looks right) but in our generated document it doesn’t.

<0xF067AF71.asc>

[K-B-STUDIO]

Hi List.

This text is Pangram for Persian, presenting Jomhuria font 

[Khaled Hosny]

On Tue, Jun 30, 2015 at 10:51:52PM +0200, Lasse Fister wrote:
> On 06/30/2015 07:54 PM, Eben Sorkin wrote:
> >
> > On Jun 30, 2015, at 11:47 AM, Lasse Fister <la...@graphicore.de

> > <mailto:la...@graphicore.de>> wrote:
> >
> >> Hi List.
> >>
> >> Kourosh, I applied the kerning from the UFO you sent me. Please check
> >> if your kerning is applied correctly.
>
> Kourosh answered
>
> On 06/30/2015 07:10 PM, Kourosh Beigpour wrote:
>
> > It seems something went wrong (we have the kerning here but in the
> wrong side)
> > Please let me know, if i did it in the wrong way
> > Please compare the pictures, that's what i can see in Glyphapp (the
> kerning looks right) but in our generated document it doesn't
>
> So that may be a problem with either: Glyphs, ufo2fdk or Sortsmill :-/
> I'll also try to solve this one. Maybe some LTR/RTL confusion in one of
> these softwares.

I fixed some RTL-related kerning bugs in Sorts Mill rather recently, do
you have them. Also, where can I find the fea file to give it a look?

> > Some of the glyph remming is there because the it is more
> > compatible/standard in the new way. Scommaacent for instance needs to
> > be a unicode name to avoid some conflicts.
> >
> Hm, we inherited the glyph names. You basically say that also Amiri is
> broken in hindsight to these conflicts? Is there a good source for
> problems related to this? What breaks when certain glyphs have the wrong
> name (that is not our build)?

I don’t see any Scommaacent in Amiri, but anyway it is a deprecated name
but nothing serious would happen if you use it (in the places where
glyph names matter, PDF text extraction, they must support even the
deprecated names for backward compatibility).

Regards,
Khaled

[Lasse Fister]

On 06/30/2015 11:19 PM, Khaled Hosny wrote:
> On Tue, Jun 30, 2015 at 10:51:52PM +0200, Lasse Fister wrote:
>> On 06/30/2015 07:54 PM, Eben Sorkin wrote:
>>> On Jun 30, 2015, at 11:47 AM, Lasse Fister <la...@graphicore.de
>>> <mailto:la...@graphicore.de>> wrote:
>>>
>>>> Hi List.
>>>>
>>>> Kourosh, I applied the kerning from the UFO you sent me. Please check
>>>> if your kerning is applied correctly.
>> Kourosh answered
>>
>> On 06/30/2015 07:10 PM, Kourosh Beigpour wrote:
>>
>>> It seems something went wrong (we have the kerning here but in the
>> wrong side)
>>> Please let me know, if i did it in the wrong way
>>> Please compare the pictures, that's what i can see in Glyphapp (the
>> kerning looks right) but in our generated document it doesn't
>>
>> So that may be a problem with either: Glyphs, ufo2fdk or Sortsmill :-/
>> I'll also try to solve this one. Maybe some LTR/RTL confusion in one of
>> these softwares.
> I fixed some RTL-related kerning bugs in Sorts Mill rather recently, do
> you have them.

Rather not. Thanks for the hint!

> Also, where can I find the fea file to give it a look?

https://github.com/Tarobish/Jomhuria/blob/master/sources/kern-arabic.fea
That was created using ufo2fdk from a ufo created with GlyphsApp.

>
>>> Some of the glyph remming is there because the it is more
>>> compatible/standard in the new way. Scommaacent for instance needs to
>>> be a unicode name to avoid some conflicts.
>>>
>> Hm, we inherited the glyph names. You basically say that also Amiri is
>> broken in hindsight to these conflicts? Is there a good source for
>> problems related to this? What breaks when certain glyphs have the wrong
>> name (that is not our build)?
> I don’t see any Scommaacent in Amiri,

We don't have or had it either. It was an example for an old-style name,
I guess.

> but anyway it is a deprecated name
> but nothing serious would happen if you use it (in the places where
> glyph names matter, PDF text extraction, they must support even the
> deprecated names for backward compatibility).

Interesting! This is a use for glyph names that's not internal to the
font as in features and marks etc. I didn't know about that.
Is there anything else where glyphs names are (mis-)used?

L.

[Khaled Hosny]

Hmm, I think the kerning is wrong here, I see things like:

pos @kern1.MMK_L_BehInti uni0676.fina -30;

But this will just subtract 30 units from the advance width of the rightmost
glyph, which is not enough as you need to move it 30 units to the left
as well, so it needs to be:

pos @kern1.MMK_L_BehInti uni0676.fina <-30 0 -30>;

This is broken in FontForge as its class kerning supports only advance
width adjustments and other adjustments will be silently dropped.
Sorts Mill fixes this partially by expanding the class kerning (as if
the enum keyword was used), but this will increase file size. Until this
is properly fixed, you can instead use contextual positioning:

pos @kern1.MMK_L_BehInti' <-30 0 -30> uni0676.fina;

But I didn’t benchmark this to see if it results into slower rendering.

> >>> Some of the glyph remming is there because the it is more
> >>> compatible/standard in the new way. Scommaacent for instance needs to
> >>> be a unicode name to avoid some conflicts.
> >>>
> >> Hm, we inherited the glyph names. You basically say that also Amiri is
> >> broken in hindsight to these conflicts? Is there a good source for
> >> problems related to this? What breaks when certain glyphs have the wrong
> >> name (that is not our build)?
> > I don’t see any Scommaacent in Amiri,
> We don't have or had it either. It was an example for an old-style name,
> I guess.

Where can I find the actual list of changed glyph names?

> > but anyway it is a deprecated name
> > but nothing serious would happen if you use it (in the places where
> > glyph names matter, PDF text extraction, they must support even the
> > deprecated names for backward compatibility).
> Interesting! This is a use for glyph names that's not internal to the
> font as in features and marks etc. I didn't know about that.

Yes, in certain PDF generation scenarios, all information about input
characters are lost and all you left with is glyph names, so Adobe have
a heuristic[1] to guess the Unicode value from
standardised glyph names.

Regards,
Khaled

1. https://github.com/adobe-type-tools/agl-specification

[Khaled Hosny]

My last mail was sent prematurely.

On Tue, Jun 30, 2015 at 11:52:47PM +0200, Lasse Fister wrote:

> Is there anything else where glyphs names are (mis-)used?

It has been said that some parts deep inside Apple font stack work
differently when the font does not have glyph names, but I don’t know
what is the extent of this or whether it depends on any particular way
of naming glyphs.

Regards,
Khaled

[Lasse Fister]

On 07/01/2015 02:06 AM, Khaled Hosny wrote:

On Tue, Jun 30, 2015 at 11:52:47PM +0200, Lasse Fister wrote:

On 06/30/2015 11:19 PM, Khaled Hosny wrote:

On Tue, Jun 30, 2015 at 10:51:52PM +0200, Lasse Fister wrote:

On 06/30/2015 07:54 PM, Eben Sorkin wrote:

On Jun 30, 2015, at 11:47 AM, Lasse Fister <la...@graphicore.de
<mailto:la...@graphicore.de>> wrote:

Hi List.

Kourosh, I applied the kerning from the UFO you sent me. Please check
if your kerning is applied correctly.

Kourosh answered

On 06/30/2015 07:10 PM, Kourosh Beigpour wrote:

It seems something went wrong (we have the kerning here but in the

wrong side)

Please let me know, if i did it in the wrong way
Please compare the pictures, that's what i can see in Glyphapp (the

kerning looks right) but in our generated document it doesn't

So that may be a problem with either: Glyphs, ufo2fdk or Sortsmill :-/
I'll also try to solve this one. Maybe some LTR/RTL confusion in one of
these softwares.

I fixed some RTL-related kerning bugs in Sorts Mill rather recently, do
you have them.

Rather not. Thanks for the hint!

My Sorts Mill is updated now.

Also, where can I find the fea file to give it a look?

https://github.com/Tarobish/Jomhuria/blob/master/sources/kern-arabic.fea
That was created using ufo2fdk from a ufo created with GlyphsApp.

Hmm, I think the kerning is wrong here, I see things like:

pos @kern1.MMK_L_BehInti uni0676.fina -30;

But this will just subtract 30 units from the advance width of the rightmost
glyph, which is not enough as you need to move it 30 units to the left
as well, so it needs to be:

pos @kern1.MMK_L_BehInti uni0676.fina <-30 0 -30>;

Ok, so probably the ufo2fdk script should generate this for right to left kerning, but it can't know from the way ufo stores its kerning data. This is probably a problem with UFO as a format(?). UFO has only very simple support for kerning:

http://unifiedfontobject.org/versions/ufo2/kerning.html

and also:

http://unifiedfontobject.org/versions/ufo3/kerning.html

The latter has a passage about writing direction:

The kerning data is writing direction neutral. For text written left-to-right, the left-most glyph is the key in the top level dictionary. For text written right-to-left, the right-most glyph is the key in the top level dictionary. For example, given the pair LG, written left-to-right, the L is the key in the top dictionary and the G is the sub-dictionary. Given the pair GL, written right-to-left, the G is the key in the top dictionary and the L is the key in the sub-dictionary.

But given that you say, that we need to know the writing direction to make such a "simple" kern pair for RTL script, just stating that "data is writing direction neutral" is not enough. Or do I miss here something?

Probably in the end we would have to mark the ufo kern pairs somehow as rtl then ufo2fdk could generate the rtl-pair style when they happen in the data.

This is broken in FontForge as its class kerning supports only advance
width adjustments and other adjustments will be silently dropped.
Sorts Mill fixes this partially by expanding the class kerning (as if
the enum keyword was used), but this will increase file size. Until this
is properly fixed, you can instead use contextual positioning:

pos @kern1.MMK_L_BehInti' <-30 0 -30> uni0676.fina;

But I didn’t benchmark this to see if it results into slower rendering.

Ok, thanks. I can try both. I'd prefer the Sorts Mill default. It wouldn't require any action on the feature code when Sorts Mill is updated.

Some of the glyph remming is there because the it is more
compatible/standard in the new way. Scommaacent for instance needs to
be a unicode name to avoid some conflicts.

Hm, we inherited the glyph names. You basically say that also Amiri is
broken in hindsight to these conflicts? Is there a good source for
problems related to this? What breaks when certain glyphs have the wrong
name (that is not our build)?

I don’t see any Scommaacent in Amiri,

We don't have or had it either. It was an example for an old-style name,
I guess.

Where can I find the actual list of changed glyph names?

I made some info:

These are the glyphs that have unicodes and got renamed. Using the unicodes, It was easy to make the mapping.

uni0300 : gravecomb => uni0300
uni0301 : acutecomb => uni0301
uni0122 : uni0122 => Gcommaaccent
uni0303 : tildecomb => uni0303
uni0156 : uni0156 => Rcommaaccent
uni0145 : uni0145 => Ncommaaccent
uni0146 : uni0146 => ncommaaccent
uni0137 : uni0137 => kcommaaccent
uni0123 : uni0123 => gcommaaccent
uni0136 : uni0136 => Kcommaaccent
uni0237 : uni0237 => dotlessj
uni0157 : uni0157 => rcommaaccent
uni0323 : dotbelowcomb => uni0323
uni013b : uni013B => Lcommaaccent
uni013c : uni013C => lcommaaccent
uni015e : Scedilla => uni015E
uni015f : scedilla => uni015F


I did not try to map name changes for glyphs without unicode values, but here is at least something:

(`old - new`) these are the glyph names that are in the old font but not in the new font:

gravecomb.cap, dotbelowcomb, f_i, uni0237, uni013C, uni013B, uni1E10, uni1E11, figuredash, uni203E, uni1E96, acutecomb, Scedilla, uni0122, uni0123, uni0146, uni0308.narrow, gravecomb, uni2213, uni0145, scedilla, uni1E29, uni0307, uni0327.cap, uni1E28, napostrophe, uni2015, uni0137, uni0136, f_l, uni0157, uni0156, tildecomb.cap, uni2042, acutecomb.cap, tildecomb


(`new - old`) these are the glyph names that are in the new font but not in the old font:

circumflex, lozenge, caron.cap, uni1E20, uni0180, kcommaaccent, macron.cap, enspace, circumflex.cap, dieresis.cap, acute.cap, hungarumlaut.cap, breve.cap, thinspace, uni01F2, uni01F3, uni01F1, uni018F, uni1E5A, uni1E5B, uni1E5C, uni1E5D, uni1E5E, uni1E5F, Kcommaaccent, tilde, aeacute, uni1E8F, uni1E8E, DEL, dotlessj, tilde.cap, estimated, uni015F, uni015E, uni0218, uni0219, space, approxequal, ring.cap, lessequal, uni01EA, gcommaaccent, ncommaaccent, grave.cap, AEacute, uni1E47, Ncommaaccent, uni021A, uni021B, rcommaaccent, Lcommaaccent, .notdef, notequal, integral, gtilde, ring, Gcommaaccent, partialdiff, trademark, uni01C5, uni01C4, uni01C7, uni01C6, uni01C9, uni01C8, pi, uni01CA, uni01CC, uni01CB, uni01CE, uni01CD, uni01CF, dotaccent.cap, Rcommaaccent, Delta, zerowidthspace, uni1E21, CR, greaterequal, uni0324, uni2113, uni0323, Gtilde, uni1E36, uni1E37, lcommaaccent, uni1E38, uni1E39, uni0259, NULL, uni030F, florin, Omega, uni1E43, uni1E42, product, i.dot, infinity, uni1E46, uni1E45, uni1E44, commaaccent, uni01EB, uni1E49, uni1E48, uni0303, uni0300, uni0301, fi, fl, nbspace, uni1E3B, uni1E3A, uni01D0, uni01D1, uni01D2, uni01D3, uni01D4

Yes, in certain PDF generation scenarios, all information about input
characters are lost and all you left with is glyph names, so Adobe have
a heuristic[1] to guess the Unicode value from
standardised glyph names.

Regards,
Khaled

1. https://github.com/adobe-type-tools/agl-specification

It has been said that some parts deep inside Apple font stack work
differently when the font does not have glyph names, but I don’t know
what is the extent of this or whether it depends on any particular way
of naming glyphs.

Thanks.

Regards, Lasse

[Dave Crossland]

On 30 June 2015 at 23:35, Lasse Fister <la...@graphicore.de> wrote:

I fixed some RTL-related kerning bugs in Sorts Mill rather recently, do
you have them.

Rather not. Thanks for the hint!

My Sorts Mill is updated now.

I don't see updates to the docker resources, though, which makes me wary of them; I think the way containers go stale is their biggest problem, and why I'm veering towards systems like pip and homebrew that make it easy to build tools from source... 

https://github.com/Tarobish/Jomhuria/blob/master/tools/docker_fontbuilder/Dockerfile

https://github.com/graphicore/docker-sortsmill

[Lasse Fister]

On 07/01/2015 05:39 AM, Dave Crossland wrote:

On 30 June 2015 at 23:35, Lasse Fister <la...@graphicore.de> wrote:

I fixed some RTL-related kerning bugs in Sorts Mill rather recently, do
you have them.

Rather not. Thanks for the hint!

My Sorts Mill is updated now.

I don't see updates to the docker resources, though, which makes me wary of them; I think the way containers go stale is their biggest problem, and why I'm veering towards systems like pip and homebrew that make it easy to build tools from source... 

That's where GitHub's Git Large File Storage (LFS) comes into the play (which I don't use yet). I rebuilt the images here locally. That executed the dockerfiles. These dockerfiles pull from git and compile the stuff. I don't need to update the dockerfiles (unless the build process of the software I use doesn't change). The final docker image is 4.102 GB on my local disk. (It could be made smaller if all the git-repos would be deleted again, before saving them to the image.)

> I think the way containers go stale is their biggest problem

You are right. But it is both good and bad, depending on the situation. If a project was not touched for a long while that old stale container may be the only way to build it, since the project data got stale, relative to the fresh software. So, the good thing is that I can ship a build environment that works with the state of project, no matter what happens anywhere else.

[Dave Crossland]

On 30 June 2015 at 23:57, Lasse Fister <la...@graphicore.de> wrote:

I can ship a build environment that works with the state of project, no matter what happens anywhere else.

If you think this is a superior approach, before starting work on the next project I'd like you to document this such that others can learn the approach. 

I hope the daily 3 part email will be a great help in this regard. 

[Khaled Hosny]

> > the key in the top level dictionary. For example, given the pair /LG/,
> > written left-to-right, the /L/ is the key in the top dictionary and
> > the /G/ is the sub-dictionary. Given the pair /GL/, written
> > right-to-left, the /G/ is the key in the top dictionary and the /L/ is

> > the key in the sub-dictionary.
>
> But given that you say, that we need to know the writing direction to
> make such a "simple" kern pair for RTL script, just stating that "data
> is writing direction neutral" is not enough. Or do I miss here something?

I think so, there need to be a way to signal what direction the kerning
will be used for (and it needs to be explicit, any heuristic is bounding
to give wrong results for some cases).

The old names follow Adobe Glyph List For New Fonts[1], unlike the new
ones, so they are the more correct ones.

> I did not try to map name changes for glyphs without unicode values, but
> here is at least something:
>
> (`old - new`) these are the glyph names that are in the old font but not
> in the new font:

Well, “f_l, f_i” etc. is the correct way to name ligatures, not “fl,
fi”. I didn’t check the rest, but I’m pretty sure that the names I used
are the recommended ones.

Regards,
Khaled

1. https://github.com/adobe-type-tools/agl-aglfn

[Dave Crossland]

On 30 June 2015 at 13:54, Eben Sorkin <sorki...@gmail.com> wrote:

We might want to show the font in use which we anticipate as likely/appropriate. i am guessing book covers, magazines, food or other packaging. Places where style is a big deal. This is not going to be the sort of thing that would be used for signs or long text. - Kourosh what do you think?  

The stuff Kourosh posted on G+ is good, I think.

From the other threads:

On 1 July 2015 at 00:48, Eben Sorkin <sorki...@gmail.com> wrote:

Begin forwarded message:

From: Eben Sorkin <sorki...@gmail.com>

Subject: quick test

Date: June 30, 2015 at 9:44:38 PM EDT

To: Lasse Fister <la...@graphicore.de>, Kourosh Beigpour <taro...@gmail.com>

Cc: GWF discuss <googlefontdir...@googlegroups.com>

Looking at this I think that the overall size of the Latin should come down because to my eye the Latin overwhelms the Arabic.

I'm not sure if this is true; I know some Arabic (Tahoma) are scaled way too small, but this seems okay to me from the top of my head not looking at anything else directly. Did you compare to other Latin+Arabic fonts?

 

I was also thinking that making the Latin either wider so that the wide kashidas are echoed or narrower so that the narrow tall forms are echoed could make sense. We could also really change things in a big way and go with reverse contrast Latin like this:

http://typecache.com/image_news/796_1.jpg

On 1 July 2015 at 02:43, Eben Sorkin <sorki...@gmail.com> wrote:

Very quick and dirty reverse contrast. This would need to be heavier. Maybe the stems could taper at the base and swell as they rise as well. :-)

I think this is a very cool Latin, but it might be too fanciful for widest possible utility. I understand there is a graphic urge to make the forms morphologically similar, but I think its better to have a more abstract similarity - to pair latin/other scripts by typographic utility and emotional genre. 

When I travel in the Arabic world, I see this 'fatface' style all the time, even used on the elevator notice in my hotel - https://goo.gl/photos/gixsV6rXRURoBBxK9 - and superficially matched stuff like this shops sign - https://goo.gl/photos/L7wqVB6yqdqfibRy7 - looks silly. The whole album is here, some really silly stuff like trying to snap a photo of a horse from a taxi stood in traffic and lurching forward so I only snapped its rear end, and me wound up in a 'luxury' Cairo barber experience where I thought I was going to come out looking like The Joker ;) https://goo.gl/photos/7J6dRvPrWp4QtBfi8

Anyway, my point is that with the first image above, the elevator notice would be okay with mixed latin/arabic, but the reverse contrast font would not be appropriate; not quite like that shop sign but in that direction. This direction makes sense with the examples that Kourosh posted, but the type is (I hope) going to find much wider uses so I think a normal contrast is appropriate. 

There is some other 'bottom heavy' stuff in the modular catalog though, so maybe this would come in handy later ;)

-- 

Cheers
Dave

[Lasse Fister]

I do now generate kerning data like this:

pos @kern1.MMK_L_BehInti uni0676.fina <-30 0 -30 0>;

or for positive numbers:

pos @kern1.MMK_L_BehInti uni06A5.medi <60 0 60 0>;

source here: https://github.com/Tarobish/Jomhuria/blob/master/sources/kern-arabic.fea

made with this: https://github.com/Tarobish/Jomhuria/blob/master/tools/getKernFeatureFromUFO.py

Overall the situation improved, but I can spot some cases where we have tiny gaps between glyphs.

@Kourosh: is that because the kerning is too much or the "reserve" baseline is not enough for the applied kerning? Or is there still something wrong with the treatment of the kerning data itself?

The following screenshots are from: http://tarobish.github.io/Jomhuria/#texts/text1

Setting the font-size of the .testcontent class to "75 em" using firebug.

There are more examples like this. Note the last two cases, they are extremely subtle.

Before Kerning گیر :


After Kerning  گیر :



After Kerning ین :


After Kerning تو :

[Lasse Fister]

@Eben

I was just looking into this with the additional information we gathered
here in the thread. More below.

On 07/01/2015 01:01 PM, Khaled Hosny wrote:

It is correct that the old names are in the "Adobe Glyph List For New
Fonts". Your glyph names are partly in the older "Adobe Glyph List" [1]
and some are in both for example "Scedilla" but you chose the uniXXXX
form. How do you choose those names? Is there another list somewhere
(FontLab)?

Given that the names before where "legal" as of a document that adobe
publishes, I wonder if we really need that renaming at all. The f_i
ligature thing is described in the Adobe Glyph List Specification[2].
That's why these names are not in the aglfn.

If we don't change the old names, I don't have to work through a lot of
files to make sure the old functionality keeps on working. However, if
there is a good reason to have the names changed in your work flow, I'd
ask you for a mapping: a text file with "oldname;newname" per line. So I
can write code to rename the glyphs prior the merging in the build
script (which is probably also messy when we start to add kerning). Even
if we decide to keep the new names, that mapping would be helpful.

Thanks,
Lasse.

1. https://github.com/adobe-type-tools/agl-aglfn/blob/master/glyphlist.txt
2.
https://github.com/adobe-type-tools/agl-specification#6-assigning-glyph-names-in-new-fonts

[Khaled Hosny]

On Wed, Jul 01, 2015 at 08:23:01PM +0200, Lasse Fister wrote:
> @Kourosh: is that because the kerning is too much or the "reserve"
> baseline is not enough for the applied kerning? Or is there still
> something wrong with the treatment of the kerning data itself?

This probably a rounding error, and can be addressed by following this
recommendation:
https://www.microsoft.com/typography/cursivescriptguidelines.mspx

Regards,
Khaled

[Eben Sorkin]

This is a bit broad brush. I don’t think he is right here in every case.

>>
>>> I did not try to map name changes for glyphs without unicode values, but
>>> here is at least something:
>>>
>>> (`old - new`) these are the glyph names that are in the old font but not
>>> in the new font:
>> Well, “f_l, f_i” etc. is the correct way to name ligatures, not “fl,
>> fi”. I didn’t check the rest, but I’m pretty sure that the names I used
>> are the recommended ones.

I am pretty sure is definitely Khaled is mistaken here. It is true that the ligatures beyond fl and fi should have underscores but for compatibility with older software fl and and fi are safer. Again, this can be shown and I’ll make an effort to do that.

>>
>> Regards,
>> Khaled
>>
>> 1. https://github.com/adobe-type-tools/agl-aglfn
>>
>
> It is correct that the old names are in the "Adobe Glyph List For New
> Fonts". Your glyph names are partly in the older "Adobe Glyph List" [1]
> and some are in both for example "Scedilla" but you chose the uniXXXX
> form. How do you choose those names? Is there another list somewhere
> (FontLab)?

I’ll go through each one and show you what seems to be the right answer and why I say this.

>
> Given that the names before where "legal" as of a document that adobe
> publishes, I wonder if we really need that renaming at all. The f_i
> ligature thing is described in the Adobe Glyph List Specification[2].
> That's why these names are not in the aglfn.
>
> If we don't change the old names, I don't have to work through a lot of
> files to make sure the old functionality keeps on working. However, if
> there is a good reason to have the names changed in your work flow, I'd
> ask you for a mapping: a text file with "oldname;newname" per line. So I
> can write code to rename the glyphs prior the merging in the build
> script (which is probably also messy when we start to add kerning). Even
> if we decide to keep the new names, that mapping would be helpful.

I agree. Really for most modern apps the unicode should be enough but when you get texted copied from PDFs and so on things can go wrong. It is worthwhile doing this due dilligence to make things maximally optimal.

>
> Thanks,
> Lasse.
>
> 1. https://github.com/adobe-type-tools/agl-aglfn/blob/master/glyphlist.txt
> 2.
> https://github.com/adobe-type-tools/agl-specification#6-assigning-glyph-names-in-new-fonts
>
> --
> Lasse Fister
>
> Tel.: +49 (160) 949 106 15
>
> Glückstraße 7
> 90763 Fürth
>
> Visit www.graphicore.de
>

> --
> You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
> To post to this group, send email to googlefon...@googlegroups.com.
> Visit this group at http://groups.google.com/group/googlefonts-discuss.

> To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/5594555F.6050608%40graphicore.de.

[Eben Sorkin]

Thanks for signaling your preference Dave.

I’ll run with that and make some additional variants to see what scale width and so on give us the sweetest match. Now I think the weight and contrast probably need to rise. 

-e.

On Jul 1, 2015, at 10:55 AM, Dave Crossland <da...@lab6.com> wrote:

On 30 June 2015 at 13:54, Eben Sorkin <sorki...@gmail.com> wrote:

We might want to show the font in use which we anticipate as likely/appropriate. i am guessing book covers, magazines, food or other packaging. Places where style is a big deal. This is not going to be the sort of thing that would be used for signs or long text. - Kourosh what do you think?  

The stuff Kourosh posted on G+ is good, I think.

>From the other threads:

On 1 July 2015 at 00:48, Eben Sorkin <sorki...@gmail.com> wrote:

Begin forwarded message:

From: Eben Sorkin <sorki...@gmail.com>

Subject: quick test

Date: June 30, 2015 at 9:44:38 PM EDT

To: Lasse Fister <la...@graphicore.de>, Kourosh Beigpour <taro...@gmail.com>

Cc: GWF discuss <googlefontdir...@googlegroups.com>

<PastedGraphic-2.png>

Looking at this I think that the overall size of the Latin should come down because to my eye the Latin overwhelms the Arabic.

I'm not sure if this is true; I know some Arabic (Tahoma) are scaled way too small, but this seems okay to me from the top of my head not looking at anything else directly. Did you compare to other Latin+Arabic fonts?

 

I was also thinking that making the Latin either wider so that the wide kashidas are echoed or narrower so that the narrow tall forms are echoed could make sense. We could also really change things in a big way and go with reverse contrast Latin like this:

http://typecache.com/image_news/796_1.jpg

On 1 July 2015 at 02:43, Eben Sorkin <sorki...@gmail.com> wrote:

Very quick and dirty reverse contrast. This would need to be heavier. Maybe the stems could taper at the base and swell as they rise as well. :-)

<PastedGraphic-3.png>

I think this is a very cool Latin, but it might be too fanciful for widest possible utility. I understand there is a graphic urge to make the forms morphologically similar, but I think its better to have a more abstract similarity - to pair latin/other scripts by typographic utility and emotional genre. 

When I travel in the Arabic world, I see this 'fatface' style all the time, even used on the elevator notice in my hotel - https://goo.gl/photos/gixsV6rXRURoBBxK9 - and superficially matched stuff like this shops sign - https://goo.gl/photos/L7wqVB6yqdqfibRy7 - looks silly. The whole album is here, some really silly stuff like trying to snap a photo of a horse from a taxi stood in traffic and lurching forward so I only snapped its rear end, and me wound up in a 'luxury' Cairo barber experience where I thought I was going to come out looking like The Joker ;) https://goo.gl/photos/7J6dRvPrWp4QtBfi8

Anyway, my point is that with the first image above, the elevator notice would be okay with mixed latin/arabic, but the reverse contrast font would not be appropriate; not quite like that shop sign but in that direction. This direction makes sense with the examples that Kourosh posted, but the type is (I hope) going to find much wider uses so I think a normal contrast is appropriate. 

There is some other 'bottom heavy' stuff in the modular catalog though, so maybe this would come in handy later ;)

-- 

Cheers
Dave

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To post to this group, send email to googlefon...@googlegroups.com.
Visit this group at http://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAEozd0wTx5%3DxxXUa9b5Tjqos_4SL-4pxExPvMXRQV%2BDoFP1Dcw%40mail.gmail.com.

[Khaled Hosny]

I checked every single one in the list above, all the names I used are
included in AGLNF, while all the names you used are not, except the uni*
names. Of course the uni* ones are always fine, but the names they are
replacing was fine as well.

> >>> I did not try to map name changes for glyphs without unicode values, but
> >>> here is at least something:
> >>>
> >>> (`old - new`) these are the glyph names that are in the old font but not
> >>> in the new font:
> >> Well, “f_l, f_i” etc. is the correct way to name ligatures, not “fl,
> >> fi”. I didn’t check the rest, but I’m pretty sure that the names I used
> >> are the recommended ones.
>
> I am pretty sure is definitely Khaled is mistaken here. It is true
> that the ligatures beyond fl and fi should have underscores but for
> compatibility with older software fl and and fi are safer. Again, this
> can be shown and I’ll make an effort to do that.

What old software and safer in what sense? I’m genuinely curios.

The fi and fl ligatures were unencoded, so f_i and f_l are the only
valid names for them, as long as AGL specification is concerned. I
didn’t use the legacy encoded slots in purpose to discourage people from
using the legacy presentation forms character in text, and since this is
mainly an Arabic font it is not expected to be used in legacy
environments that lack OpenType support.

Regards,
Khaled

[Dave Crossland]

On 1 July 2015 at 18:25, Khaled Hosny <khale...@eglug.org> wrote:

didn’t use the legacy encoded slots in purpose

Including Latin, like http://www.fileformat.info/info/unicode/char/fb01/index.htm ?

[Khaled Hosny]

Yes, my comment was specifically about those (of course it is the same
argument against using Arabic Presentation Forms or even PUA for
encoded glyphs).

Regards,
Khaled

[Dave Crossland]

I can see that for Arabic Presentation Forms, there are single glyph forms for combinations of letters that can be recreated by correctly co-positioning individual letters, so not including them is important for filesize reduciton. 

But since the single glyph form of the fi ligature has to be there anyway, if the OT code to substitute it is also there, why not encode it with fb01? :)