Re: st: No german umlauts in -gr export- .pdf filenames? (Win7, Stata 12 or 13)

[Sergiy Radyakin <serjradyakin@gmail.com>]

Dear Stefan,

I confirm the same problem with both Stata 12 and 13 on Windows Server 2008.
Screenshot is here:
http://radyakin.org/statalist/2013110401/umlauts.png
Graphic file itself is valid, even though the file name is garbled.

Note that Stata officially does not work with unicode. To me this
means that anything out of 32-127 range (ASCII printable) may or may
not work. If possible, avoid the use of these characters. Especially
in the file names. From my experience it complicates backups later,
and confuses people who are not familiar with the language.

The fact that Stata selectively mistreats file name in this procedure
only is most probably a bug. As a workaround I wanted to suggest
outputting to a file with a 'simpler' name, then renaming using the OS
function !rename. This did not work either. I did not pursue this way,
but found that Stata's "copy simplename strangename" worked, and I
suggest you using this as a workaround.

Hope this helps.

Best,
   Sergiy Radyakin



On Sun, Nov 3, 2013 at 11:52 PM,  <Stefan.Gawrich@hlpug.hessen.de> wrote:
> Dear Statalisters,
>
> I have sent this question to Stata support but it seems that the answer is not too easy.
>
> My work PC has been migrated from XP to Win7 recently (german language setting) and since that I encountered that -graph export- with the ".pdf" options doesn't display german umlauts in filenames. Any other -graph export- fileformat writes correct filenames.
>
> Here's my example .do file:
> (If you can't see umlauts in the .do file, well, there are some...)
>
> ******************************
> local path "G:\temp\"
> sysuse auto, clear
> sc mpg weight
> graph save   `path'test_umlauts_üöäÜÖÄß.gph, replace
> graph export `path'test_umlauts_üöäÜÖÄß.pdf, replace
> graph export `path'test_umlauts_üöäÜÖÄß.emf, replace
> *****************************
>
> -graph export- with the "pdf"-option shows the correct filenames with umlauts in Statas results window.
> But the written .pdf filename has black diamonds with question marks instead of umlauts on my PC.
>
>
> Can anyone from the german speaking Stata community confirm this behaviour in Win7 with Stata 12 or 13?
>
> Best wishes
>
> Stefan Gawrich
> Dillenburg
> Germany
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Phil Schumm [mailto:pschumm@uchicago.edu]
> Gesendet: Donnerstag, 7. August 2008 19:29
> An: statalist@hsphsun2.harvard.edu
> Betreff: Re: st: Using foreach and two local macros
>
> On Aug 7, 2008, at 10:46 AM, Gawrich Stefan wrote:
>> Looping over parallel lists is indeed a very powerful feature.  To
>> keep it flexible you'll often use a second extended function (word
>> count) with the forval command.
>>
>> local x "1 2"
>> local y "3 4"
>> local n : word count `x'
>> forvalues i = 1/`n' {
>> local x1 : word `i' of `x'
>> local y1 : word `i' of `y'
>> di `x1'+2*`x1'+`y1'
>> }
>>
>> But in my view the syntax has two drawbacks:
>> 1) It needs a lot of lines. So it bloats your do-files expecially
>> when you use it with more than two locals.  (I often use it for
>> batch graph creation where variables, selections, titles and
>> settings can make up to ten locals)
>> 2) You have to create new local names inside the loop, which makes
>> it confusing and error prone
>>
>> So sometimes I find it convenient to use that good old (not longer
>> documented) "for" command again.
> <snip>
>
>
> When you brought this up 2 years ago:
>
>      http://www.stata.com/statalist/archive/2006-03/msg00522.html
>
> I pointed out that you can use nested lists as an alternative, and
> Nick elaborated on that:
>
>      http://www.stata.com/statalist/archive/2006-03/msg00545.html
>      http://www.stata.com/statalist/archive/2006-03/msg00546.html
>
> IMHO, nested lists are often a better approach.  For example, consider
>
>
>      loc foo `" "1 a I" "2 b II" "3 c III" "'
>      foreach item of loc foo {
>          tokenize `"`item'"'
>          di "`1' `2' `3'"
>      }
>
>
> versus
>
>
>      loc l1 1 2 3
>      loc l2 a b c
>      loc l3 I II III
>      for num `l1' \ any `l2' \ any `l3': di "X Y Z"
>
>
> In the first case, when you construct the macro foo, you are keeping
> the values 1, a, and I all together as a group, which is much less
> prone to error than when you have to construct l1, l2, and l3
> separately (e.g., the lengths may not match, you may get the ordering
> of the sub-items messed up, etc.).  Thus, if you are constructing
> your list(s) by hand, I would argue that the former is much better
> (and much easier to maintain if you have to add/drop parts of each
> item in the list later on).
>
> Now, if you are in the position where l1, l2, and l3 are generated
> programmatically, you just need to assemble them into a nested list.
> Python has a function for this called -zip()-:
>
>
>      >>> l1 = [1,2,3]
>      >>> l2 = ['a','b','c']
>      >>> l3 = ['I','II','III']
>      >>> zip(l1,l2,l3)
>      [(1, 'a', 'I'), (2, 'b', 'II'), (3, 'c', 'III')]
>
>
> It would not be difficult to write a Mata function to do this;
> alternatively, one could imagine StataCorp adding an extended macro
> function (i.e., something like {local | global} macname : list zip
> macnames).
>
>
> -- Phil
>
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/statalist/faq
> *   http://www.ats.ucla.edu/stat/stata/
>
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/faqs/resources/statalist-faq/
> *   http://www.ats.ucla.edu/stat/stata/

*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/