I have a requirement to covert UCS2 to following code pages
Chinese: gb2312
Japanese: shift_jis
Russian : cp1251
Hungrian, Polish and Cesky: cp1252
Default:cp1250
I could see that items 3-5 are supported in newlib iconv library.
For gb2312 or gbk I could see that it's supported in Cygwin-windows only. Is there a feasibility issue to support gb2312 for embedded cortex M controllers?
I can see Jis implementation in newlib and but is not available for Cygwin.Is It available for embedded cortex M controllers?
What is the difference between jis and shit-jis,is it compatible with euc_jp
I have tried cp1250,cp1251 and cp1252 successfully but not able to figure out a path for gb2312 and shift_jis
I have partially able to do for shift_jis by creating tables using
1. wget ftp://sourceware.org/pub/newlib/newlib-4.2.0.20211231.tar.gz
2. tar -xvf newlib-4.2.0.20211231.tar.gz
3. cd newlib/libc/iconv/ccs/
4. wget https://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/SHIFTJIS.TXT
5. ./mktbl.pl -S SHIFTJIS.TXT
6. cd ../ces/
7. ./mkdeps.pl
Related
Perl 6 does have classes that include common OSs for specifying paths, as well as $*SPEC which contains the file specification. New paths use by default current value of SPEC. However, it's not clear at all, from the documentation, if doing something like
mkdir IO::Path.new( 'a/b/c' );
is going to work correctly across all operating systems, or you need to specifically create OS-dependent code. Any idea?
I'm trying this on Windows 7 (one of the OSes you seem to be mostly interested in according to tags), using
This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03
implementing Perl 6.d.
And it seems to work just like that
> with mkdir IO::Path.new('a/b/c') { say .e; say .absolute }
True
C:\rakudo\a\b\c
The directory is indeed created properly.
Note that IO::Path takes an IO::Spec object defaulting to $*SPEC in its constructor, so the necessary OS-dependent part is available to the object. In Rakudo the IO::Spec is indeed used by mkdir through .absolute.
There also is a roast test about / in an IO::Path becoming \ on Windows.
As Elizabeth Mattijsen pointed out, Windows seems to just support forward slashes by itself. Others claim that this has been the case forever:
Actually, every version of Windows, and every version of MS-DOS from 2.0 on, has accepted "/" as a path delimiter.
On a Windows 10 Enterprise VM:
C:\Users\me>c:/rakudo/bin/perl6 -e "mkdir IO::Path.new( 'a/b/c' )"
C:\Users\me>tree a
Folder PATH listing
Volume serial number is xxx
C:\USERS\ME\A
└───b
└───c
One day I just zipped a file with Chinese character called 周國賢 - 密封罩.flac, to a zip, using bandizip & designated encoding to utf-8.
And then I try to unzip it in my MacbookPro, which is (probably) using Macintosh as encoding. The file unzipped is called ©P∞ÍΩ - ±K´ ∏n.flac, which does not match the above Chinese name.
So, I try to test about the encoding, and found that Macintosh->big5 would return the Macintosh mysterious symbol into Cantonese, but have some unmatching characters: 周衰�璀� - 密封罩.flac.
I have tried another file: §˝µ· - ¨ı®ß.ape: and it actually output the correct name of the file: 王菲 - 紅豆.ape
So, here is my question: how do I unzip a file that with big5 chinese character properly and without any information loss? Or how do I zip a file correctly to prevent information loss/ incorrect characters? (edit #2: you can use bandizip to zip the file into utf-8 encoding)
BTW, The encoding converter I am using is https://r12a.github.io/apps/encodings/, which could be quite helpful for you to check for encoding. Don't forget to click change encodings shown. And I am not the owner of the encoding converter.
edit #1: I have found that the setting in bandizip is wrong...well sorry for the inconvenience caused. Nonetheless, I figure out that The Unarchiver in Mac Apple Store can unzip big5 correctly. This can be a workaround, but still I don't know how to unzip big5 characters properly WITHOUT any loss.
history:
I am trying to get GNU "barcode" to produce bar codes that I can add to pick lists, and work orders. I am trying to create the bar-codes as small as the physical labels that we use in the warehouse (2.5"x0.75") using the following command:
#barcode -b 'TEXTTOENCODE' -c -e code39 -u in -g 2.5x0.75 -u in -p 2.5x0.75 > bc.ps
problem:
No matter what page size parameters I use, I only seem to be able to produce US Letter size documents.
When I open the resulting file (in KDE Document Viewer) the file properties are reported as: 'US Letter, Portrait (216 × 279 mm)' as seen below:
KDE Document Viewer - Sample Barcode image with picture properties.
GNU barcode version below:
# barcode --version
barcode frontend (GNU barcode) 0.98
Any suggestions as to what I might be doing wrong, are welcome.
Thanks,
'Skye
You are doing nothing wrong, it's just that barcode uses an obsolete DSC comment to declare paper size, which isn't recognized by the PS viewer. Maybe try using option -E? This will crop the document to just the bar code.
which encodings do windows use when reading filenames from zip archive thru zip folders?
as far as I know
cyrillic is represented as cp866 and
central european - cp437
what about other?
Portuguese
Español (Spanish)
Français (French)
Polski (Polish)
Türkçe (Turkish)
Deutsch (German)
Italiano (Italian)
العربية (Arabic)
Farsi
ไทย (Thai)
中文 (Chinese)
日本語 (Japanese)
한국어 (Korean)
Tiếng Việt (Vietnamese)
I think first seven of this are in cp437.
Chinese may be in Big5
But I know nothing about others.
According to Apache Commons Compress Zip package documentation it's the platforms default encoding.
Windows' "compressed folder" feature doesn't recognize any flag or
extra field and creates archives using the platforms default encoding
- and expects archives to be in that encoding when reading them.
Just installed Ghostscript 8.54 for Windows.
Does anyone know of the minimum parameters to pass to gswin32c.exe to make it convert, say, someFile.eps to someFile.eps.pdf?
Since the question was about the "minimum parameters to pass to gswin32c.exe to make it convert, say, someFile.eps to someFile.eps.pdf", let me give an answer:
c:/path/to/gswin32c.exe ^
-sDEVICE=pdfwrite ^
-o c:/path/to/output.pdf ^
c:/path/to/input.eps
or even shorter:
gswin32c ^
-sDEVICE=pdfwrite ^
-o output.pdf ^
input.eps
This will use the builtin, default parameters for Ghostscript. The most important of which, from the top of my head, for the most recent version of Ghostscript are:
-dPDFSETTINGS=/default ........ roughly the same settings as Adobe Distiller uses for "screen" with the following differences:
-r720x720 .................................. resolution: 720 dpi (bitmaps/fonts requiring conversion to bitmap)
-dColorConversionStrategy=/LeaveColorUnchanged ... (Distiller's "screen" uses =/sRGB)
-dCompatibilityLevel=1.4 .... (Distiller's "screen" uses =1.3)
-dEmbedAllFonts=true [*]......... (Distiller's "screen" uses =false)
-dOptimize=false [**] ............... (Distiller's "screen" uses =true)
-dDownsample{Color,Gray,Mono}Images=false ... (Distiller's "screen" uses =true)
[*] By default, Ghostscript does not embed the classical "Base 14"-PostScript fonts. To enforce that, use an extra parameter (at the end of the command line!) like -c "<</NeverEmbed [ ]>>setdistillerparams" -f c:/path/to/input.pdf.
[**] Ghostscript's pdfwrite device cannot "optimize" a PDF when it is writing it the first time. To optimize, you have to call Ghostscript again for a second pass, using special parameters (you may also try -dOptimize=true).
BTW, Ghostscript's most recent version is 8.71, available here: ghostscript.com/relases.
Under Windows, ps2pdf and other utilities are located in C:\Program Files\gs\gs#.##\lib as .bat and .cmd files. This isn't exactly obvious, especially if you're looking for .exe files.