Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From   <[email protected]>
To   <[email protected]>
Subject   st: No german umlauts in -gr export- .pdf filenames? (Win7, Stata 12 or 13)
Date   Mon, 4 Nov 2013 08:52:45 +0100

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:[email protected]] 
Gesendet: Donnerstag, 7. August 2008 19:29
An: [email protected]
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/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index