Re: Location of liblouis translation tables
Sebastian Humenda, le mer. 25 oct. 2023 18:05:41 +0200, a ecrit: > Samuel Thibault schrieb am 25.10.2023, 14:22 +0200: > >Sebastian Humenda, le lun. 16 oct. 2023 02:16:34 +0200, a ecrit: > >> Any ideas? > > > >It seems some changes in the tables file broke cups-filter's ability to > >find them. Could you try to change in > > > >/usr/share/cups/braille/cups-braille.sh > > > >locale: > > > >into > > > >language: > > I expect you meant `locale:` within the if and elif? Yes. > I've selected "default for language, grade 2" in the web interface and > it seems indeed to work. Ok, good :) > The error log now contains other errors: > > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > > I have been trying to print a standard HTML file (plain HTML, no js, etc.). I don't remember how that's supposed to convert. You probably want to raise the cups log level to see more details on the conversion process. Samuel
Re: Location of liblouis translation tables
Hi Samuel sorry for the other message. All the ethernet replugging (due to trying to debug the printer) and I overlooked that I didn't fetch your e-mail: Samuel Thibault schrieb am 25.10.2023, 14:22 +0200: >Sebastian Humenda, le lun. 16 oct. 2023 02:16:34 +0200, a ecrit: >> Any ideas? > >It seems some changes in the tables file broke cups-filter's ability to >find them. Could you try to change in > >/usr/share/cups/braille/cups-braille.sh > >locale: > >into > >language: I expect you meant `locale:` within the if and elif? I've selected "default for language, grade 2" in the web interface and it seems indeed to work. >> I have also seen that there seem to be official Index drivers these days in >> printer-driver-indexbraille. Has anyone tried them out? > >That driver just sends the document to the embosser, and lets the >embosser perform all conversions etc. Alright, I see. The error log now contains other errors: E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF file E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF file I have been trying to print a standard HTML file (plain HTML, no js, etc.). Thanks Sebastian signature.asc Description: PGP signature
Re: Location of liblouis translation tables
Hi I have figured out that the cups-filter seems to internally use grep to find the corresponding liblouis translation table. The standard is to use the locale, which is in my default de_DE. Since the table is named `de-g0*`, it doesn't find it. Explicitly selecting a language helps. I should probably file a bug. Cheers Sebastian signature.asc Description: PGP signature
Re: Location of liblouis translation tables
Hello, Sebastian Humenda, le lun. 16 oct. 2023 02:16:34 +0200, a ecrit: > I've set up the cups filters to print with my Index Everest V5. > The Cups interface shows an error when I try to print: > "Could not find LibLouis table with locale de_DE" > I've installed these packages: > liblouis-bin liblouis-data liblouis20 liblouisutdml-bin liblouisutdml-data > liblouisutdml9 liblouisxml-bin liblouisxml-data liblouisxml1 > > Any ideas? It seems some changes in the tables file broke cups-filter's ability to find them. Could you try to change in /usr/share/cups/braille/cups-braille.sh locale: into language: ? I'll try to get that fixed in bookworm's cups-filters, since the patch is very trivial. > I have also seen that there seem to be official Index drivers these days in > printer-driver-indexbraille. Has anyone tried them out? That driver just sends the document to the embosser, and lets the embosser perform all conversions etc. Samuel
Location of liblouis translation tables
Hi I've set up the cups filters to print with my Index Everest V5. The Cups interface shows an error when I try to print: "Could not find LibLouis table with locale de_DE" I've installed these packages: liblouis-bin liblouis-data liblouis20 liblouisutdml-bin liblouisutdml-data liblouisutdml9 liblouisxml-bin liblouisxml-data liblouisxml1 Any ideas? I have also seen that there seem to be official Index drivers these days in printer-driver-indexbraille. Has anyone tried them out? Thanks Sebastian signature.asc Description: PGP signature
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello Samuel, On Tue, Oct 24, 2023 at 07:59:44PM +0200, Samuel Thibault wrote: >What do you get when you paste into another graphical application such >as pluma or gedit? And conversely when pasting into tmux? When I am in a tmux session and copy multiline text with brltty's COPY_RECT command * the text is inserted in reverse order and with broken lines in another terminal, no matter if there is a tmux session running or not * is inserted correctly in pluma. This does not happen if I copy the multiline text with brltty's COPY_RECT command when I am not in a tmux session. >> I've also tested it with the new show flatview contents feature of orca 45 >> during working in a tmux session. There the same issue is happening if I >> copy multiline text and insert it using different editors. > >I don't see the relation between flatview and copy? Are you using a copy >feature from orca? No. I just tested if the same thing occures if I do not use brltty's COPY_RECT feature to get multiline content into the clipboard. If I open a tmux session and copy multiline content from this session with the new flatfview feature from orca and not with brltty's COPY_RECT feature it is also broken when I insert this multiline text in an editor running in a terminal. Inserting the same content in pluma works fine. So it does not matter if copying content with brltty or with orca, but it seems to be related where the content of the clipboard is inserted. I hope the problem is more clear now. Ciao, Schoepp
