Graphics support and unicode input

[pkess]

Hello there,

i recognized your project last weekend and as you may have seen i already copied and modified the code a bit. As your code looks really good and i think there may be others who can participate from this i would like to share my developments with this.
I really need the graphics feature and my implementation already prints some graphics but there are some points to work on before this can be used.

One big point is the input in form of a converted unicode file. This produces some problems with a file containing graphics commands as the graphics commands are converted with the unicode table as well as the real characters. Can you explain why you don't apply the translation table as part of this program?

[zub2]

Hi. You are implementing graphics? Wow! :)

As for your question: in my usecase the input was in one of two obscure character encodings (CP852 or the even more obscure "Kamenici"). So a conversion is necessary, I can't just feed individual bytes as-they-are to Cairo. And I preferred to do the conversion in a separate tool. But you are right: The conversion on input can work for text, and for some simple escapes (ESC followed by bytes<128). But if there is an escape containing anything above 127, then this causes a lot of pain.

I agree the conversion must be done inside, and only after the escape sequences are decoded.

I implemented only the basic functionality I needed and never got to implementing more. I would be glad if you create a pull request so that I can integrate your changes. Then I can add the character conversion (and perhaps clean up the input handling as w/o unicode handling it can be simplified a bit).

It would be great if you could also provide test files - for the features you implement. There are some already in the directory tests but these are in utf-8, so I will have to adapt these.

[pkess]

Hello,
thank you for your fast response. I just created a pull request with a file i am using for my development at the moment. So if we want to improve this all i think the first change should be the other existing files to be converted back to some codepage related files and implement the codepage translation herein.
Do you think so too? Do you have the time to implement something on that or should i start editing the code and implement some mechanics to support raw chars as input of the preprocessor and some interface for the codepage translator?

I think it would be greate to implement the codepage translation in a similar way as the printer code preprocessor inside of the CairoTTy module

[zub2]

I agree with your proposal. So, there could be two new methods in CairoTTY:

• operator<<(char)
• operator<<(const std::string&)

and CairoTTY would be using a converting object (that it would receive in its ctor) to convert these into gunichar or Glib::ustring. (And the old operator<<()s for uni char/string could then be removed.)

Did I get your proposal?

Unfortunately I'm really busy these days. If you need a solution soon, feel free to implement this. Otherwise I will try to find some time for this during the weekend, but I'm not sure if I manage. :-(

[pkess]

Nice to hear from you. I implemented something similar. I will rebase some of my changes on your master branch to create a pr for this tomorrow.

[rusq]

@pkess You may want to look at this project too: https://github.com/nzeemin/ukncbtl-utils/wiki/ESCParser

It already renders graphics (but doesn't render overprint/bold)

I'm attaching test_Graphics_invoice.CP850.prn rendered by this utility
output.pdf

[pkess]

Hi @rusq, sorry for my late reply. I just had a look into this project and it seems like it renders the graphics very good. But it does not render all signs correctly like horizontal lines.
Also i think it is a big advantage of the dotprint project that it outputs the text as a real text and it supports the bold command. I already implemented something to support all the commands i need for this program but it is a very poor implementation from my side at the moment.

Thank you for this hint