Thank you for offering to help.
I uploaded the same image in both EPS and PDF format.
The EPS was produced on a Sun system (wally). There are 2 PDF files respectively generated on the same Sun system and on a Linux/Red-Hat nodes cluster (heimdall).
The files can be accessed at the following URL:
http://www.trusoftdev.za.net/maura
I'd like to summarize the history of such files.
The EPS file has been created by a Tcl/Tk program through saving to the disk the canvas image.
The Tk code that generates the EPS file can be found in the Tk generic dir in the Tk source distribution
TkCanvasPs.c or something like it
(see:
http://tktoolkit.cvs.sourceforge.net/tktoolkit/tk/generic/tkCanvPs.c?...
and
http://tktoolkit.cvs.sourceforge.net/tktoolkit/tk/generic/prolog.ps?v...
)
The PDF files were generated on both systems by ps2pdf13.
I also uploaded two TXT files , "Heimdall-Info.txt" and "Wally-Info.txt", containing all the info that I could find about the two platform (wally and heimdall) on which "ps3pdf13" produces different results.
Thank you in advance,
Maura Edelweiss M.
I have the following image format translation problem. I wonder if someone can advice me about a possible solution.
A Tcl/Tk code builds an image on the canvas (Tcl/Tk jagon) and is saved to an eps file by the Tcl "canvas --> postscript" command.
While the eps (this format is Tcl-imposed) file looks fine, the pdf version, obtained through the Linux
"ps2pdf13" platform-independent conversion, has all the histogram_bar marks and labels messed up.
I build the histogram_bar marks and labels by using a font family "adobe-courier' declared in the Tcl program in order to be able at run-time to dynamically change its size according to the user's selections.
The histogram_bar marks, that get screwed up by ps2pdf conversion, consist of powers of 10 whose exponent can be either positive or negative ( for instance 10 to the power12 or 10 to the power -11). The
base (10) is displayed through a bigger font with respect to the exponent. The font size pair (respectively for the base and the exponent) is selected depending on the GUI window size (Extra-Large, Large, Medium, Small).
Since the canvas picture can have two
radiobutton-selectable aspect-ratios, namely 1:1 and 16:9, all fonts are "rescaled " (size changed accordingly) back and forth when the aspect ratio is changed.
Is the abobe
Thank you in advance for your help,
Maura
Hi All,
Here an intresting issue on parted command.
I have a device of size 1074 MB and i tried to create partitions with parted
command. The intresting issue is, the start position of first partition is
not constant. The following snippet explain you more on this.
lx88245:~ # parted -s /dev/sdc print
Disk geometry for /dev/sdc: 0kB - 1074MB
Disk label type: msdos
Number Start End Size Type File system Flags
lx88245:~ # parted -s /dev/sdc mklabel msdos
lx88245:~ # parted -s /dev/sdc mkpart p 0 1065
lx88245:~ # parted -s /dev/sdc print
Disk geometry for /dev/sdc: 0kB - 1074MB
Disk label type: msdos
Number Start End Size Type File system Flags
1 1kB 1065MB 1065MB primary type=83
lx88245:~ # parted -s /dev/sdc rm 1
lx88245:~ # parted -s /dev/sdc print
Disk geometry for /dev/sdc: 0kB - 1074MB
Disk label type: msdos
Number Start End Size Type File system Flags
lx88245:~ # parted -s /dev/sdc mklabel msdos
lx88245:~ # parted -s /dev/sdc mkpart p 0 1069
lx88245:~ # parted -s /dev/sdc print
Disk geometry for /dev/sdc: 0kB - 1074MB
Disk label type: msdos
Number Start End Size Type File system Flags
1 32kB 1069MB 1069MB primary ext3 type=83
lx88245:~ # parted -s /dev/sdc rm 1
lx88245:~ # parted -s /dev/sdc mklabel msdos
lx88245:~ # parted -s /dev/sdc mkpart p 0 1071
lx88245:~ # parted -s /dev/sdc print
Disk geometry for /dev/sdc: 0kB - 1074MB
Disk label type: msdos
Number Start End Size Type File system Flags
1 1kB 1071MB 1071MB primary type=83
lx88245:~ #
In the first ( parted -s /dev/sdc mkpart p 0 1065) and third ( parted -s
/dev/sdc mkpart p 0 1071) case the start position of first partition is 1 KB
( first block ) but in second case ( parted -s /dev/sdc mkpart p 0 1069) it
is ( 32 kB). Can anyone explain it why it is happening like this ?
is it bug in parted command ?
Your help is appreciated ?
Regards
Masthan
On Thursday 24 August 2006 21:08, Benjamin Sonnemann wrote:
> Guten Tag,
>
> natürlich habe ich noch Interesse. Meine Zeugnis Kopien müssten heute
> zwischen 16:45 und 17:15 bei ihnen eingegangen sein, agesendet von der
> Firma FarbTex, da ichselber kein Fax besitze. Telefonisch bin ich
> eigentlich immer zu erreichen, da müssen sie einen schlechten Moment
> erwischt haben. Meine Mobilnummner für solche Fälle ist:
> 01729402893
> Nach 22:00 stelle ich allerdings meine Telefone ab.
>
> Mit freundlichen Grüßen
> Benjamin Sonnemann
Sorry, aber nachdem das nun ja nicht die erste mail diesen Monat ist und so
langsam wirklich nervt:
Bist du zu dä**** deinen Mailclient zu bedienen oder zuminstest vor dem Senden
den Empfänger der Mail zu prüfen?
Danny
Hi ,
At the time of booting , SUSE 10 (ia64 m/c) chowing that, qla2xxx driver is
not supportd by novell , tainted flag is enabled ( Not exactly this , iam
saying in my own words ).
Is qla2xxx driver supports SLES 10 ?
Thanks in advance
Regards
Masthan
> From: Per Jessen
> peter burden wrote:
> > Per Jessen wrote:
> >> I should explain what I'm really doing here:
> >> I sscanf() the timestamp into a 'tm' struct, and I correct the year and
> >> month such that they comply with what 'tm' expects. Then I convert to
> >> a number of seconds since the epoch using mktime() and subtracting the
> >> number of seconds as specified in the offset part of the timestamp -
> >> e.g. +0200 becomes -7200 seconds.
> >> But my number of seconds always ends up being off by 3600 seconds, i.e.
> >> 3600 seconds less than it should be.
> > I wonder if this is something to do with daylight saving times settings.
> > Your +0200 log file offset may be composed of +1 hour for your
> > Central European time zone and +1 hour for local daylight saving
> > time.
>
> Yep, that is correct.
>
> > If, when you "hand crafted" the struct tm maybe you didn't set the
> > tm_idst field, mktime() would apply a further 1 hour correction since
> > daylight saving time is in force locally - see tzset(3).
>
> True, I haven't set isdst - problem is, I would much prefer not having
> to find out if we've DST or not ...
Yeah, DST is a bear. I gather you're trying to generate epoch time from a timestamp that is already recorded in a log. If the DST state is not recorded in the log as part of the time stamp and the system observes DST then you' are going to have to determine it yourself . And that's for the timestamp time, not for the "current" system time, so you have to figure out if it WAS DST in the past not if it IS DST now.
If you can change the system to use UTC or to record UTC in the log that might help simplify the problem.
peter burden wrote:
> Per Jessen wrote:
>> I should explain what I'm really doing here:
>> I sscanf() the timestamp into a 'tm' struct, and I correct the year and
>> month such that they comply with what 'tm' expects. Then I convert to
>> a number of seconds since the epoch using mktime() and subtracting the
>> number of seconds as specified in the offset part of the timestamp -
>> e.g. +0200 becomes -7200 seconds.
>> But my number of seconds always ends up being off by 3600 seconds, i.e.
>> 3600 seconds less than it should be.
>>
>
> I wonder if this is something to do with daylight saving times settings.
> Your +0200 log file offset may be composed of +1 hour for your
> Central European time zone and +1 hour for local daylight saving
> time.
Yep, that is correct.
> If, when you "hand crafted" the struct tm maybe you didn't set the
> tm_idst field, mktime() would apply a further 1 hour correction since
> daylight saving time is in force locally - see tzset(3).
True, I haven't set isdst - problem is, I would much prefer not having
to find out if we've DST or not ...
/Per Jessen, Zurich
>>
>> /Per Jessen, Zürich
>>
>>
>>
>
>
I'm post-processing loglines from a log written by syslog-ng - maybe not
the best of interfaces, but the log is the best record of the activity
I'm checking for.
The loglines have a timestamp like this: 2006-08-15T20:33:57+0200
I need to convert that to a number of seconds since 1970-01-01 00:00:00
UTC. I looked at strptime, but that doesn't take the GMT-offset into
account, so I decided to sscanf() the timestamp into a 'tm' structure.
Then I use mktime to turn into a number seconds.
The question is - mktime() looks at the local timezone settings ...
which I'd rather it didn't. OK, I could fiddle with the TZ variable
and make it UTC, but as I'm multi-threaded this could have undesired
effects elsewhere.
AFAICT, syslog-ng does not have an option for also logging the timestamp
as the number of seconds since the epoch, which would obviously
otherwise have been the best option. I might still look into patching
syslog-ng.
Any other suggestions?
/Per Jessen, Zürich
I have a data collection system that collects data to hot swappable
disks. Is there a way I can determine the type of media a file will be
written to? Let me explain:
I have a diskless boot system. The Linux OS and all come from over the
network. So, unless I mount a disk, anything written anywhere will be to
RAM. If I mount a disk, the file will be written to the disk and not
RAM. How can I determine that it is a disk and not RAM? The disks are
mounted via udev. The mount point exists as a directory whether there is
a disk mounted over it or not, so I cannot use that to see. I want to
know if there is a disk mounted where I am writing, or somewhere above
it.
As I read this question I too think it sounds odd. But I really would
like to know. Maybe statvfs()? If the size of the media is greater than
some test limit, (RAM in the machine perhaps) then it must be some
mounted thing? Is there a better way?
--
Roger Oberholtzer
OPQ Systems AB
Ramböll Sverige AB
Kapellgränd 7
P.O. Box 4205
SE-102 65 Stockholm, Sweden
Tel: Int +46 8-615 60 20
Fax: Int +46 8-31 42 23
(If this is too non-suse-specific for this list, just shout. But the
platform it will run on is SUSE 10.x)
Back in the days of character displays (non-X at least), if I wanted
quick key press notification I simply set up the keyboard file
descriptor to send SIGIO when a user pressed a key. Worked a charm.
Then came X...
I still need quick key press notification. However, multiple window GUIs
make this very difficult. The key press is tied to a window and must be
processed in the proper context. I buy that.
But what if I need the fastest and most reliable (in terms of latency)
access to a key press in a program running under X? The reason for this
is that I have an application where a user indicates an activity by a
key press. Delays are to be avoided.
I have been toying with using some USB key device (e.g., www.xkeys.com)
instead of the keyboard. But isn't there a delay in USB 1 transmissions?
Perhaps this is less than the delay in X. in getting the key to me.
Any ideas? Maybe I can get key presses more direct from X and pass back
the ones I am not interested in? There is a caveat: I do X via embedded
Tk. The scripting capability is really handy. But the Tk library has
access to X.
--
Roger Oberholtzer
OPQ Systems AB
Ramböll Sverige AB
Kapellgränd 7
P.O. Box 4205
SE-102 65 Stockholm, Sweden
Tel: Int +46 8-615 60 20
Fax: Int +46 8-31 42 23