Kamile Demir

Thank you for reporting this! To clarify, is this occurring with AFDKO version 3.9.2? If so, are you able to check if this issue is also happening in the previous...

Implemented in #1576 . Here's an example of [what the groups.plist should look like!](https://github.com/adobe-type-tools/afdko/blob/develop/tests/tx_data/input/cid_roundtrip/testCID.ufo/groups.plist)

Question (mainly for @skef ): Last year, Zachary and I had structured this so that the cid and iFD mappings would be moved from each .glif file to a CIDMap...

Question about the key naming: Shall we discuss if we want keys to have "com.adobe.type" or not? Currently, the code should support keys that do and don't have it (since...

> Was the previous code ever really in production? @skef No, it only ever stayed in PR #1380 and we never ended up merging. Then the plan became to rewrite...

> If there is a mismatch between the number of FDArrays defined in lib.plist and the number of FDSelect groups in groups.plist we should error out. Right now if we...

> Kind of related to my last comment running tx alone on a UFO outputs an extra empty FontDict. Running `tx -t1` and outputting to a file is fine and...

@hatchzo also added: > The zigzag/loop paths should be corrected by design and tx should report detailed information on parse errors. But I think the most serious problem is checkoutlineufo....

@punchcutter In my new commits I bumped the version numbers & fixed uforead for non-cid-keyed UFOs with glifs named `cidXXXXX`. I added a test for it too, does that test...

Changes in this PR will need to be redone due to the [replacing tx parser with libxml2 project. ](https://github.com/adobe-type-tools/afdko/projects/7) Keeping this as reference for when I work on this on...