bugFree UCS Outline Fonts - Bugs: bug #40058, Naming of Serbian Localised Glyphs...

 
 

bug #40058: Naming of Serbian Localised Glyphs wrong?

Submitter:  Alessandro Ceschini <aleces>
Submitted:  Wed 18 Sep 2013 01:42:23 PM UTC
   
 
Category:  individual character(s) Severity:  3 - Normal
Item Group:  glyph name issue Status:  Proceeding
Privacy:  Public Assigned to:  Stevan_White
Open/Closed:  Open Release:  * 2012-05-03
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 26 Sep 2013 12:00:28 PM UTC, comment #19: 

Hello Steve,

I don't want to start a flame here, but... Rosella is right, George Duffner's workaround DOES work, I tried it myself by downloading his modified font, if you implemented it you'd do a great service to us all.

I repeat it: WE KNOW IT'S NOT YOUR FAULT, but sometimes the job of a good font designer is precisely to devise workarounds to patch software deficiencies.

Regards,

Alessandro Ceschini <aleces>
Thu 26 Sep 2013 11:41:19 AM UTC, comment #18: 

But Georg Duffner demonstrated this DOES work, even with evince! You don't seem moved by this attempt! Are you sure you're not taking it personal? You always seem very picky about this issue.

By the way, where should I signal this bug? Is there something like a XeLaTeX bug list?

And as I said, the strange thing is that this happens only with Cyrillic, not Greek alternate glyphs, Greek alternate glyphs, whether upright or italic, are perfectly recognised and copied.

Rosella Capriotti <rosy58>
Thu 26 Sep 2013 09:21:03 AM UTC, comment #17: 

Hi,

I ruled out this work-around for numerous reasons -- it's just so wrong in so many ways.  Just the beginning of the list: it's ineffective in all but the simplest cases, it amounts to a duplication of information (that is certain to break).

On top of this, the implementation in sofware that is supposed to use it is very spotty.  Nobody it seems implements the whole thing.  Most don't implement it at all -- probably because it's stupid.

And all along, this was never a font issue.  It's an issue with PDF generating software, and should be resolved there.

It shouldn't be my business, and I already have too much to do.  But OK.  I'm working on a correct solution to the problem.

Steve White <Stevan_White>
Group administrator
Tue 24 Sep 2013 01:24:32 PM UTC, comment #16: 

Dear Steve,

So, you ruled out the workaround because you don't like it or because it spawns troubles elsewhere? I don't get it!

Rosella Capriotti <rosy58>
Sun 22 Sep 2013 05:57:44 PM UTC, comment #15: 

But... Georg implemented this on the font and indeed it does work, I mean I can copy the characters with the modified font. Which consequences are you talking about?

Alessandro Ceschini <aleces>
Sun 22 Sep 2013 12:50:02 PM UTC, comment #14: 

The unicode-strings will not be impemented as glyph names.

I appreciate your desires, and as I said I am working on a solution.

What you are proposing does not do what you think it does. I have spent a lot of time researching this, trying it in different environmens.  It's very very poor.  And it has bad consequences.

A better solution will come around.

Steve White <Stevan_White>
Group administrator
Sat 21 Sep 2013 07:54:40 PM UTC, comment #13: 

Dear Steve,

Your reaction kinda scared me: I was hesitant to write here because I really don't want things to flare up as they did concerning the CYRILLIC KSI shape.

Now, My humble opinion is that Rosella is right: we're asking for legacy support here, buggy or not, it's a workaround, NOT the solution, but something that can easily plug the gap and fulfill user expectations for the moment. But you seem to want "my way or the highway".

Alessandro Ceschini <aleces>
Sat 21 Sep 2013 07:07:06 PM UTC, comment #12: 

Steve, take it easy! It's just a stopgap quick fix we're asking for! We know it's not the solution, but as you said in some other topics, sometimes you have to devise some workarounds because of software deficiencies. It's called legacy support, isn't it? I don't understand why you're getting so ideological, of course you've got to solve the bigger problem but if quick fixes are available why not implementing them?

I hope you won't get angry at me! :)

Rosella Capriotti <rosy58>
Sat 21 Sep 2013 06:45:10 PM UTC, comment #11: 

Hi guys.

We won't be re-naming any glyphs to resolve an algorithmic deficiency in PDF generating software.  It would maybe fix the one or two letters in your specific case in some software.  But this is sweeping the problem under the rug.

The glyph re-naming will not help Indic languages.  Forget it.

Responding to this issue (here and elsewhere) has taken a great deal of time, that might possibly have gone toward a correct solution.  I have stated that I am working on that.

If you're willing to discuss a solution to the bigger problem, let's do talk.  Otherwise, please, let us do our work.

Steve White <Stevan_White>
Group administrator
Sat 21 Sep 2013 03:07:38 PM UTC, comment #10: 

Hello Steve, Georg and Alessandro,

This is a very interesting issue, I confirm I'm experiencing the same hassle, it'd be nice if you Steve could implement a quick fix so that evince correctly recognises Serbian glyphs, otherwise, as Alessandro has said, the text, although beautiful, is to all extent and purpose, broken, even if copying/pasting isn't an issue, you can't even carry out a search through the text because lots of glyphs aren't associated with the corresponding character: for instance if I search for CYRILLIC BE, I'll get no results, because the Serbian localised glyph isn't recognised as a variant of CYRILLIC BE, and so on.

Very frustrating, indeed :(

P.S.
I was wondering why this problem doesn't show up in Greek, you've been implementing scores of alternate glyphs and all of them are correctly recognised/searched/copied/pasted.

Rosella Capriotti <rosy58>
Sat 21 Sep 2013 02:58:42 PM UTC, comment #9: 

OK, so now the glyphs are all right in the svn version, all they need is the right names, by the way which are the names of all the glyphs, including SHA, so that Steve may implement them?

I hope he will, because he doesn't seem too fond of that naming issue, he seemed rather disgruntled at the prospect of following the Adobe standard, but, hey, let's consider it a workaround, we need this font to work, it's useless to implement Serbian glyphs if the text is to all extent and purpose broken.

Alessandro Ceschini <aleces>
Sat 21 Sep 2013 02:46:38 PM UTC, comment #8: 

Yes, the ge and pe issue is the LinLibertine-type bug in these fonts which I explained in my first mail to the thread on the XeTeX-list. The locl lookup for serbian in FreeSerifItalic substitutes ge with imacron and pe with icyrillicmacron (or however it’s called here). While this accidentally looks correctly in the italic it is not in most other styles. The font needs a gecyrillic.serb and pecyrillic.serb, if I’m not mistaken, this issue has been fixed some time between the font-version on CTAN and the current svn one (the glyphnaming issue being untouched and extended to these two).

Georg Duffner <georgd>
Sat 21 Sep 2013 02:40:09 PM UTC, comment #7: 

OK, I've just copied it and I get the same output as yours. BUT... GE and PE are not the correct glyphs for the upright form: they rather look like respectively a Latin and a Cyrillic I with a macron above. The other three glyphs are correct. So, maybe the naming of GE and PE is still incorrect, I suppose?

Alessandro Ceschini <aleces>
Sat 21 Sep 2013 02:32:13 PM UTC, comment #6: 

I’ve renamed be too, just forgot to mention it. Can you copy it from the pdf-file I sent?
From that one c/p results in: бīдӣт
If yes, then please post the LaTeX-code you use to test.

Cave: I modified the font not with the intention to fix it, but to demonstrate where the problem lies. It’s a systematic problem in these fonts and should be fixed globally throughout these fonts.

Georg Duffner <georgd>
Sat 21 Sep 2013 02:04:39 PM UTC, comment #5: 

OK, but you said you renamed PE, DE and TE, but I presume you left BE untouched because the naming is supposedly correct; yet I cannot copy even BE, all I get is strange hieroglyphics LO classifies as "Hindi".

Is there maybe something wrong in the way I compile the document in XeLaTeX? Can I see your tex file?

Thank you very much!

Alessandro Ceschini <aleces>
Sat 21 Sep 2013 01:46:06 PM UTC, comment #4: 

No, I’m using evince as well.

Georg Duffner <georgd>
Thu 19 Sep 2013 11:19:46 AM UTC, comment #3: 

Also see here: http://tug.org/pipermail/xetex/2013-September/024745.html

However, this workaround doesn't work for evince; I presume Mr. Duffner uses adobereader as pdf viewer.

Alessandro Ceschini <aleces>
Wed 18 Sep 2013 06:42:14 PM UTC, comment #2: 

Hello Steve,

Basically, you're telling me that this is a XeTeX bug and has nothing to do with how you name the glyphs, am I wrong?

Alessandro Ceschini <aleces>
Wed 18 Sep 2013 02:14:52 PM UTC, comment #1: 

Hi, yes I remember you, Alessandro.

The issue you are referring to is a recurring topic in these bug reports.

As I explained in the posting you mentioned, the failure to copy substituted (or ligated, etc) glyphs as text is due to a failure of the PDF generating software to properly fill out certain tables in the PDF file.  It is often proposed that the replacement glyphs be given ugly names that encodes how they should be interpreted as text.

I have given the ugly re-naming a try, and tested it in several software packages.  It doesn't always fail completely -- it sometimes works somewhat.  Usually it fails completely.

There is a bigger picture here.  In software that supports the font-naming scheme, it would work for your purposes.  But in the case of Indic scripts, there is no way for the scheme to work.  It cannot handle those cases.

Like many other font developers, we take the stance that the association of glyphs to characters (as needed to copy from PDF), is not solved by an ugly naming the glyphs. So we will not be doing this.

The issue is a bit complicated, and several layers of misunderstandings are usually involved.
The fact is, naming the glyphs only works for certain software, and there, it can work only partially, when much better ways to resolve the issue exist.  This was a bad solution for the problem in the first place.

This is properly the business of the software that generates PDF.  It should be able to get all the information it needs to solve your problem from the font's glyph substitution tables, which is where the mapping information is properly kept.

What I will do, is to write up some proposals and put them before the appropriate people.  I think a mostly-functining solution is not hard to obtain, and I still thinka a perfect one might be tenable.

Thanks for reminding us!

Steve White <Stevan_White>
Group administrator
Wed 18 Sep 2013 01:42:23 PM UTC, original submission:  

Hello Steve :)

I'm back, I hope you won't bother :) I know I fell out with you about the Old Slavonic Glyphs, let's forget about that, will we?

Good, I wrote to you because I saw you've already subscribed to the XeTeX mailing list and took part to that very thread: http://tug.org/pipermail/xetex/2013-September/024741.html. Now, as I've already stated, I'm not convinced this is the real issue preventing Serbian Glyphs from being recognised as just variants of standard Unicode characters. However, I think it'd be fair if you gave it a try, at least by giving them a standard name like: serb.be instead of uni04E3 which is indeed misleading.

Thanks!

Alessandro Ceschini <aleces>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rosy58 (Posted a comment)
  • -email is unavailable- added by georgd (Posted a comment)
  • -email is unavailable- added by Stevan_White (Posted a comment)
  • -email is unavailable- added by aleces (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-18 Stevan_White StatusNone Proceeding
        Assigned toNone Stevan_White

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code