That's a Very Good Question, Franck!
The truth is, Illustrator's scripting language lags *way* behind InDesign's, so converting this same script to Illustrator is not possible! (Or way too much 'extra' work, to mimick all features that InDesign has and Illy does not.)
Also, the people working with fonts and text are more likely to work in InDesign. A typical Illustrator user who needs a "custom bullet" will most likely just draw it on the fly, and copy-and-paste where necessary.
... Of course it's also possible to draw your artwork in Illustrator and then copy it into InDesign! Just be sure to change the black parts of your character to InDesign's [Black], do not use Illy's imported color (which may be CMYK or RGB).
SING without the singe? This sounds really useful for those of us who need odd bits of type -- in my case, unusual diacritics and custom Chinese characters. I've used InDesign's drawing tools for both while away from the computers with FontLab and Fontographer, and even toyed briefly with SING before Adobe suspended further development. I'm looking forward to taking IndyFont out for a test drive.
This looks great. One question : I see that IndyFonts stores the fonts within InDesign, rather than filling the system OS fonts with niche custom fonts that make no sense outside of InDesign. Great feature. Is it possible to keep the font data within the InDesign file, or, within a user's folder?
I'm thinking of cases where an InDesign template is to be worked on by people on one of those tightly controlled corporate networks (e.g. VDI networks) where software and OS files are all shared from a tightly-controlled central server. If the InDesign install itself is on a server like this (e.g. via something like Citrix), or, if the person finalising the document is editting it in InCopy, is it possible to create the custom IndyFont font in a way that they can either use, or drop in to the document? (e.g. if they can save the font to some user-specific settings folder they have access to if they don't have rights to cause changes to files in the central InDesign install).
Does that question make sense? Embedding would be ideal for shared files in cases like this, but I think I saw somewhere that no fonts can ever be embedded in an InDesign file (could be wrong). (that said, it's possible to define fonts as SVG/JS using things like Cufon, so maybe fonts created in IndyFont could be sort-of-embedded that way?)
Alanomaly, you cannot embed a font into an InDesign the same way you can embed an image (by the way, that is discouraged by those in the know as it causes extreme file bloat and a greater chance of a malfunctioning file).
But there is a good alternative: Document Installed Fonts. This is a folder inside the same folder as your document, and only when the document is opened, the fonts will show up for that one document.
I cannot recall off-hand if the IndyFont demo allows you to save a font anywhere, but the full version does (which is still In Progress and To Appear). Of course, you can always first save the font in the default location and then manually move it to another folder.
Brilliant, and thanks for the amazingly fast reply! You can save anywhere in the IndyFonts demo, and saving the font file in a document font seems ideal.
(unfortunately I can't test it and confirm it works with the corporate network here because they're all stuck with CS4 and document fonts weren't introduced until CS5, but for others, and if/when these guys ever upgrade, that should be ideal)
I saw you post about this recently in an Illustrator thread. Impressive output of the OpenType specification from InDesign, great work. What an astounding idea and solution, it looks wonderful (also nice GUI Marc), nice execution on this concept Jongware, super work. Really looking forward to find out more about this script, workflow, its release date, pricing and availability.
Hi Marc & Jongware,
This thread caught my eye when it first came out.
I was wondering what OTF features it will have in the final version.
If not included at present take them as a feature request to include in version 1.01
The bellow are important to me, as I mostly work with right to left complex scripts - i.e. Hebrew,
But there's a lot of Chinese and Arabs out there who are also quite complex, so I'm sure they would also like these features, not to mention some nice Ukrainians, Germans and some great French and Dutch blokes that occasionally roam around this forum.
1) Assign the language block of the font.
I don't want to have to look through all the English fonts to find my Hebrew font, also It can well be that the fonts won't type anything unless the correct language is set. This can be a major flaw in the font.
2) I want to be able to include multiple languages in a font so that I can have English and Hebrew text without having to change fonts.
3) If I am feeling lazy, which happens occasionally, and can't be bothered to create yet another English font I would like to be able to allocate an English font that should be used for typing English while on my Hebrew font.
4) Need to be able to tag 'marks' for diacritics with decent kerning feature for different types of marks and not just letters.
5) Discretionary ligatures "dlig" and Character composition "ccmp" tags
6) Right to left control characters
7) The marks kerning is very important and substitutions is very important to me.
This is an example of the Hebrew letter Shin with a real collection of diacritics marks. The main letter is in black the 4 different diacritics marks are colored here to show each different one.
My apologies, Trevor -- I'm going to have to say "no" to some ... well ... *most* of the above. At least for the initial version.
A few clarifications may help.
1. You cannot "assign" a language to a font. But what you actually mean is not "language", but "script". And you cannot assign that either -- InDesign simply looks at the supported character set, and if a font contains both Latin and Hebrew characters, it's stored under "Hebrew". If you inspect the current fonts in your Hebrew list, you will see most of them actually also contain Latin characters.
So as soon as your own font contains a fair amount of Hebrew, InDesign will gladly sort it under "Hebrew". And if you add more scripts (Chinese, Japanese, Thai, or Arabic), your font will be further "demoted" to group with mega-fonts such as Arial MS Unicode.
2. Uh, see the above.
3. That is a software option, not something one can encode in a font.
4. That *is* an OpenType function, but even with professional (= dedicated) software hard to do.
5. Oof! Finally something that *is* on our shortlist of "to do" (even if it may only be in a next version, or so).
6. Uh, I don't think those are supposed to be included in a font file. Even if they are (what would they "look" like?), ID would strip them out and use the appropriate *function* instead.
7. Kerning is actually quite something else. This is the same as your point #5. It works like this: for some combinations of base character + accent, you can draw a pre-defined glyph. The ccmp feature then makes sure the correct image gets used -- IF it can find a combination for the two characters.
Implementing its advanced cousin (these features are called "mark" and "mkmk") is one of the things that's hard even with Pro Font Designer software.
Thanks for the quick reply,
I'm not too convinced about point 1 but don't want to bog this thread down dicussing these issues and will probably send you a PM next week with some links.
You are certainly correct that even dedicated font programs have problems with complex font issues and the ones that deal well with them (including Arabic Kadishas and expandable letters) are very very expensive.
(My two pennies on that exciting discussion.)
Above all, hopes you have in IndyFont are very challenging for us, and that's great to have so much motivation around a simple script. A year ago, Theunis revealed the inaugural 240Kb version that already sounded like a bomb. He then offered me to contribute and complete this project—which is an honor to me. Our goal was, and still is, to achieve an unprecedented font tool for InDesign users, CS4/CS5/CS6 compliant, working on both Mac and Win platform, in a clean UI, providing quick and optimal results in the scope of an ExtendScript dev.
Users will say whether IndyFont 1.1 meets the "main needs". There will undoubtedly be a number of feature requests regarding OTF. Be confident that we'll do our best to gradually improve the product.
Thats said, IndyFont is not intended to compete with advanced OTF-wise software, or even simple font editors. It would be pretentious and counterproductive to claim we can reach that level in our specific field. As you know, OpenType is a Pandora's box (or a bottomless pit?), therefore we had to make choices and set limits to our project. As Theunis explained above, some limits may be just provisional. Others are deliberately taken to delineate our own workspace. I'm not even sure that the OpenType spec could be fully and accordingly implemented in ExtendScript, but whatever! That's not what we are focusing on. The point of the script, its great added value, lies in its accessibility within InDesign. As this is a plug-in, it takes advantage of all you can imagine being made in ID in terms of building artworks, processing outlines, addressing typographic features, etc., not to mention the InDesign GUI in itself.
My last point is that we want this product to remain very easy-to-use to non-specialists, with a minimum of prerequisites. It is clear to us that pro font designers use expert software. IndyFont is intended for those intermediate users who want to quickly and effectively job a font and some related features… in InDesign.
By the way, the new IndyFont demo version is now available:
[Click the TRY button to download, then unzip and drop the jsx as usual in your Scripts Panel folder.]
IndyFont 1.121 demo (TRY) now available.
Fixed a serious bug that could produce wrong glyph export in CS5 and CS6.
Click the TRY button to download and update: