Menu
▾
▴
libemf-devel — Discussion of libemf development
This list is closed, nobody may subscribe to it.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(14) |
Dec
(19) |
| 2004 |
Jan
(4) |
Feb
(2) |
Mar
(6) |
Apr
(3) |
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(4) |
Dec
(1) |
| 2005 |
Jan
|
Feb
(1) |
Mar
(6) |
Apr
(3) |
May
(3) |
Jun
(3) |
Jul
(7) |
Aug
(5) |
Sep
(8) |
Oct
(2) |
Nov
(2) |
Dec
(15) |
| 2006 |
Jan
(9) |
Feb
(1) |
Mar
(6) |
Apr
(11) |
May
(32) |
Jun
(34) |
Jul
(15) |
Aug
(12) |
Sep
(22) |
Oct
(56) |
Nov
(92) |
Dec
(69) |
| 2007 |
Jan
(56) |
Feb
(25) |
Mar
(31) |
Apr
(29) |
May
(18) |
Jun
(24) |
Jul
(83) |
Aug
(66) |
Sep
(32) |
Oct
(28) |
Nov
(12) |
Dec
(8) |
| 2008 |
Jan
(16) |
Feb
(25) |
Mar
(50) |
Apr
(41) |
May
(20) |
Jun
(23) |
Jul
(43) |
Aug
(26) |
Sep
(34) |
Oct
(19) |
Nov
(39) |
Dec
(50) |
| 2009 |
Jan
(97) |
Feb
(37) |
Mar
(78) |
Apr
(77) |
May
(122) |
Jun
(106) |
Jul
(82) |
Aug
(34) |
Sep
(28) |
Oct
(47) |
Nov
(14) |
Dec
(14) |
| 2010 |
Jan
(8) |
Feb
(6) |
Mar
(47) |
Apr
(55) |
May
(60) |
Jun
(65) |
Jul
(49) |
Aug
(47) |
Sep
(18) |
Oct
(13) |
Nov
(1) |
Dec
(2) |
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(3) |
Oct
(2) |
Nov
(2) |
Dec
(2) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(10) |
Dec
(1) |
| 2013 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(17) |
Jun
(3) |
Jul
(5) |
Aug
(6) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2015 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(5) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Allen B. <all...@gm...> - 2015-04-01 12:23:28
|
I had to reject your message from the mailing list because it was too large. But it sent me a copy anyway; go figure. I will look it over. if you don't mind telling me, what are you using libEMF for? Thanks, Allen On Tue, Mar 31, 2015 at 7:19 PM, Bill Crocker <wil...@an...> wrote: > Hello: > > I needed wide char string support. > (I find it hard to believe that I am the first.) > Anyway, I wrote ExtTextOutW and would > like to see it integrated back into the standard > release. > > I do not know how to do that. > I can provide the source if someone else > would like to review and integrate it > into the repository. > > Thanks. > > -- > Bill Crocker > Work: (781) 937-1382 > Home: (978) 686-3277 > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Libemf-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libemf-devel > |
|
From: Allen B. <al...@tr...> - 2015-04-01 11:24:44
|
Hi Bill: I reckon the reason ExtTextOutW isn't in there is because very few people actually use libEMF :-) You can certainly send me a patch with your changes and I'll look them over. The aspect that I'm not sure about is that wchar_t is different between windows (these days I think it's a 16-bit UTF-16 character) and most unix systems (where it is usually a USC-32 character). Do you try to take care of that difference? Allen On Tue, Mar 31, 2015 at 7:19 PM, Bill Crocker <wil...@an...> wrote: > Hello: > > I needed wide char string support. > (I find it hard to believe that I am the first.) > Anyway, I wrote ExtTextOutW and would > like to see it integrated back into the standard > release. > > I do not know how to do that. > I can provide the source if someone else > would like to review and integrate it > into the repository. > > Thanks. > > -- > Bill Crocker > Work: (781) 937-1382 > Home: (978) 686-3277 > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Libemf-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libemf-devel > -- Allen Barnett Varian Medical Systems Ph: 518-887-2930 |
|
From: Bill C. <wil...@an...> - 2015-03-31 23:21:26
|
Hello: I needed wide char string support. (I find it hard to believe that I am the first.) Anyway, I wrote ExtTextOutW and would like to see it integrated back into the standard release. I do not know how to do that. I can provide the source if someone else would like to review and integrate it into the repository. Thanks. -- Bill Crocker Work: (781) 937-1382 Home: (978) 686-3277 |
|
From: Allen B. <al...@tr...> - 2015-03-24 14:43:27
|
libemf implements a small subset of the ECMA standard. But it is a programming library, not an application. To convert a WMF or EMF file, you can try importing it into Inkscape of LibreOffice and use their SVG exporters. Allen On Tue, Mar 24, 2015 at 10:06 AM, Henein, Magdi <mh...@te...> wrote: > HI, > > Is > http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-234-v3.pdf > implements WMF and EMF on linux? > > If not, can you direct me to an WMF/EMF library that I can use on linux > lateform? > > What should I use on a linux plateform to convert EMF/EMF images to SVG ? > > > Regards, > Magdi > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Libemf-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libemf-devel > -- Allen Barnett Varian Medical Systems Ph: 518-887-2930 |
|
From: Henein, M. <mh...@te...> - 2015-03-24 14:30:42
|
HI, Is http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-234-v3.pdf implements WMF and EMF on linux? If not, can you direct me to an WMF/EMF library that I can use on linux lateform? What should I use on a linux plateform to convert EMF/EMF images to SVG ? Regards, Magdi |
|
From: Allen B. <all...@gm...> - 2012-11-07 11:38:10
|
Hi Stanislav: I uploaded an updated libEMF-1.0.7.tar.gz file to the source forge site. I just removed the "-dev" from the version name. Thanks for your patches. It's always nice to see somebody else's hard work! Allen On Tue, Nov 6, 2012 at 10:48 AM, Stanislav Ochotnicky <soc...@re...> wrote: > Quoting Allen Barnett (2012-11-06 15:23:39) >> On Tue, Nov 6, 2012 at 8:59 AM, Stanislav Ochotnicky >> <soc...@re...> wrote: >> > Hi Allen, >> > >> > I probably should have been clear in the beginning: I've already tested the >> > patches on s390,s390x,ppc and ppc64 (including make check). >> >> Sure. I just wanted to make sure I hadn't botched the patches. >> >> The only thing I >> > couldn't do was alpha support. The patch for it was in Fedora repos for some >> > time, but I didn't really analyse it that much... In any case I've re-checked >> > your 1.0.7-dev tarball and it works on these archs as well. >> > >> > I'd say that worst thing is that alleged alpha support will not work and will >> > need some more fixing by interested parties :-) >> >> I found this: http://emuvm.com/index.php?option=com_content&view=article&id=12&Itemid=8 >> but it needs an OS image. Seems like a lot of work :-) And I don't >> have access to Tru64, anyway. >> >> I make a regular release of 1.0.7 shortly. > > For the record, Gentoo developer tested this on alpha hardware so it does seem > to work after all :-) > > Thanks for being so responsive, > > -- > Stanislav Ochotnicky <soc...@re...> > Software Engineer - Base Operating Systems Brno > > PGP: 7B087241 > Red Hat Inc. http://cz.redhat.com |
|
From: Allen B. <all...@gm...> - 2012-11-06 14:23:48
|
On Tue, Nov 6, 2012 at 8:59 AM, Stanislav Ochotnicky <soc...@re...> wrote: > Hi Allen, > > I probably should have been clear in the beginning: I've already tested the > patches on s390,s390x,ppc and ppc64 (including make check). Sure. I just wanted to make sure I hadn't botched the patches. The only thing I > couldn't do was alpha support. The patch for it was in Fedora repos for some > time, but I didn't really analyse it that much... In any case I've re-checked > your 1.0.7-dev tarball and it works on these archs as well. > > I'd say that worst thing is that alleged alpha support will not work and will > need some more fixing by interested parties :-) I found this: http://emuvm.com/index.php?option=com_content&view=article&id=12&Itemid=8 but it needs an OS image. Seems like a lot of work :-) And I don't have access to Tru64, anyway. I make a regular release of 1.0.7 shortly. Thanks, Allen > > Quoting Allen Barnett (2012-11-06 14:05:04) >> Hi Stanislav: Your patches looked reasonable to me. I have applied >> them to the head of the revision tree and packed them up in a >> preliminary distribution: >> >> http://sourceforge.net/projects/libemf/files/libemf/1.0.7/libEMF-1.0.7-dev.tar.gz/download >> >> If you have access to the machines you're trying to support, I would >> appreciate it if you would give the new revision a test on each of >> them. After building, "make check" performs a brief regression test of >> the library. >> >> Also, SVN is up to date with your changes: >> >> https://libemf.svn.sourceforge.net/svnroot/libemf >> >> Thanks, >> Allen >> >> On Mon, Nov 5, 2012 at 1:06 PM, Allen Barnett <all...@gm...> wrote: >> > Thanks, Stanislav. It will be a day or so before I have time to apply >> > and test these changes, but I'll keep it at the top of my TODO list. >> > >> > Allen >> > >> > On Mon, Nov 5, 2012 at 12:20 PM, Stanislav Ochotnicky >> > <soc...@re...> wrote: >> >> Heya Allen, >> >> >> >> it's nice to have such a fast response :-) >> >> >> >> Patches attached separately. I guess I just got used to git a bit too much. >> >> As for the tarballs, feel free to send me a link to a "test" tarball and I'll >> >> verify everything is in order. >> >> >> >> Thanks, >> >> >> >> Quoting Allen Barnett (2012-11-05 15:49:21) >> >>> Hi Stanislav: Thanks for your patches. I used to have a JavaStation to >> >>> test the big endian implementation, but that went to electronics >> >>> recycling a long time ago. >> >>> >> >>> If you would be so kind as to send me your patches as separate >> >>> attachments (or in a single tar file), I would appreciate it. Also, >> >>> since I can't really test these patches on alpha, s390 or ARM, can I >> >>> send you an updated libEMF source tar file for you to check? >> >>> >> >>> Thanks, >> >>> Allen >> >>> >> >>> On Mon, Nov 5, 2012 at 8:53 AM, Stanislav Ochotnicky >> >>> <soc...@re...> wrote: >> >>> > Hi, >> >>> > >> >>> > we have recently encountered libEMF failures when compiling on ppc64 >> >>> > architecture. This seemed to be introduced in libEMF-1.0.5 with conditionals >> >>> > referencing x86_64 architecture directly instead of generic 64bit >> >>> > architecture. I have created a patch (1/4) to fix this and reference __LP64__ >> >>> > instead of __x86_64__. Next three patches add support for additional >> >>> > architectures, most notably alpha, s390/s390x and arm. >> >>> > >> >>> > If you could include these changes in your next release, it would be >> >>> > appreciated. >> >>> > >> >>> > If you'd like me to change these patches or explain details, let me know >> >>> > >> >>> > -- >> >>> > Stanislav Ochotnicky <soc...@re...> >> >>> > Software Engineer - Base Operating Systems Brno >> >>> > >> >>> > PGP: 7B087241 >> >>> > Red Hat Inc. http://cz.redhat.co >> >>> > >> >>> > >> >>> > ------------------------------------------------------------------------------ >> >>> > LogMeIn Central: Instant, anywhere, Remote PC access and management. >> >>> > Stay in control, update software, and manage PCs from one command center >> >>> > Diagnose problems and improve visibility into emerging IT issues >> >>> > Automate, monitor and manage. Do more in less time with Central >> >>> > http://p.sf.net/sfu/logmein12331_d2d >> >>> > _______________________________________________ >> >>> > Libemf-devel mailing list >> >>> > Lib...@li... >> >>> > https://lists.sourceforge.net/lists/listinfo/libemf-devel >> >> >> >> -- >> >> Stanislav Ochotnicky <soc...@re...> >> >> Software Engineer - Base Operating Systems Brno >> >> >> >> PGP: 7B087241 >> >> Red Hat Inc. http://cz.redhat.com > > -- > Stanislav Ochotnicky <soc...@re...> > Software Engineer - Base Operating Systems Brno > > PGP: 7B087241 > Red Hat Inc. http://cz.redhat.com |
|
From: Allen B. <all...@gm...> - 2012-11-06 13:05:15
|
Hi Stanislav: Your patches looked reasonable to me. I have applied them to the head of the revision tree and packed them up in a preliminary distribution: http://sourceforge.net/projects/libemf/files/libemf/1.0.7/libEMF-1.0.7-dev.tar.gz/download If you have access to the machines you're trying to support, I would appreciate it if you would give the new revision a test on each of them. After building, "make check" performs a brief regression test of the library. Also, SVN is up to date with your changes: https://libemf.svn.sourceforge.net/svnroot/libemf Thanks, Allen On Mon, Nov 5, 2012 at 1:06 PM, Allen Barnett <all...@gm...> wrote: > Thanks, Stanislav. It will be a day or so before I have time to apply > and test these changes, but I'll keep it at the top of my TODO list. > > Allen > > On Mon, Nov 5, 2012 at 12:20 PM, Stanislav Ochotnicky > <soc...@re...> wrote: >> Heya Allen, >> >> it's nice to have such a fast response :-) >> >> Patches attached separately. I guess I just got used to git a bit too much. >> As for the tarballs, feel free to send me a link to a "test" tarball and I'll >> verify everything is in order. >> >> Thanks, >> >> Quoting Allen Barnett (2012-11-05 15:49:21) >>> Hi Stanislav: Thanks for your patches. I used to have a JavaStation to >>> test the big endian implementation, but that went to electronics >>> recycling a long time ago. >>> >>> If you would be so kind as to send me your patches as separate >>> attachments (or in a single tar file), I would appreciate it. Also, >>> since I can't really test these patches on alpha, s390 or ARM, can I >>> send you an updated libEMF source tar file for you to check? >>> >>> Thanks, >>> Allen >>> >>> On Mon, Nov 5, 2012 at 8:53 AM, Stanislav Ochotnicky >>> <soc...@re...> wrote: >>> > Hi, >>> > >>> > we have recently encountered libEMF failures when compiling on ppc64 >>> > architecture. This seemed to be introduced in libEMF-1.0.5 with conditionals >>> > referencing x86_64 architecture directly instead of generic 64bit >>> > architecture. I have created a patch (1/4) to fix this and reference __LP64__ >>> > instead of __x86_64__. Next three patches add support for additional >>> > architectures, most notably alpha, s390/s390x and arm. >>> > >>> > If you could include these changes in your next release, it would be >>> > appreciated. >>> > >>> > If you'd like me to change these patches or explain details, let me know >>> > >>> > -- >>> > Stanislav Ochotnicky <soc...@re...> >>> > Software Engineer - Base Operating Systems Brno >>> > >>> > PGP: 7B087241 >>> > Red Hat Inc. http://cz.redhat.co >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > LogMeIn Central: Instant, anywhere, Remote PC access and management. >>> > Stay in control, update software, and manage PCs from one command center >>> > Diagnose problems and improve visibility into emerging IT issues >>> > Automate, monitor and manage. Do more in less time with Central >>> > http://p.sf.net/sfu/logmein12331_d2d >>> > _______________________________________________ >>> > Libemf-devel mailing list >>> > Lib...@li... >>> > https://lists.sourceforge.net/lists/listinfo/libemf-devel >> >> -- >> Stanislav Ochotnicky <soc...@re...> >> Software Engineer - Base Operating Systems Brno >> >> PGP: 7B087241 >> Red Hat Inc. http://cz.redhat.com |
|
From: Allen B. <all...@gm...> - 2012-11-05 18:07:02
|
Thanks, Stanislav. It will be a day or so before I have time to apply and test these changes, but I'll keep it at the top of my TODO list. Allen On Mon, Nov 5, 2012 at 12:20 PM, Stanislav Ochotnicky <soc...@re...> wrote: > Heya Allen, > > it's nice to have such a fast response :-) > > Patches attached separately. I guess I just got used to git a bit too much. > As for the tarballs, feel free to send me a link to a "test" tarball and I'll > verify everything is in order. > > Thanks, > > Quoting Allen Barnett (2012-11-05 15:49:21) >> Hi Stanislav: Thanks for your patches. I used to have a JavaStation to >> test the big endian implementation, but that went to electronics >> recycling a long time ago. >> >> If you would be so kind as to send me your patches as separate >> attachments (or in a single tar file), I would appreciate it. Also, >> since I can't really test these patches on alpha, s390 or ARM, can I >> send you an updated libEMF source tar file for you to check? >> >> Thanks, >> Allen >> >> On Mon, Nov 5, 2012 at 8:53 AM, Stanislav Ochotnicky >> <soc...@re...> wrote: >> > Hi, >> > >> > we have recently encountered libEMF failures when compiling on ppc64 >> > architecture. This seemed to be introduced in libEMF-1.0.5 with conditionals >> > referencing x86_64 architecture directly instead of generic 64bit >> > architecture. I have created a patch (1/4) to fix this and reference __LP64__ >> > instead of __x86_64__. Next three patches add support for additional >> > architectures, most notably alpha, s390/s390x and arm. >> > >> > If you could include these changes in your next release, it would be >> > appreciated. >> > >> > If you'd like me to change these patches or explain details, let me know >> > >> > -- >> > Stanislav Ochotnicky <soc...@re...> >> > Software Engineer - Base Operating Systems Brno >> > >> > PGP: 7B087241 >> > Red Hat Inc. http://cz.redhat.co >> > >> > >> > ------------------------------------------------------------------------------ >> > LogMeIn Central: Instant, anywhere, Remote PC access and management. >> > Stay in control, update software, and manage PCs from one command center >> > Diagnose problems and improve visibility into emerging IT issues >> > Automate, monitor and manage. Do more in less time with Central >> > http://p.sf.net/sfu/logmein12331_d2d >> > _______________________________________________ >> > Libemf-devel mailing list >> > Lib...@li... >> > https://lists.sourceforge.net/lists/listinfo/libemf-devel > > -- > Stanislav Ochotnicky <soc...@re...> > Software Engineer - Base Operating Systems Brno > > PGP: 7B087241 > Red Hat Inc. http://cz.redhat.com |
|
From: Allen B. <all...@gm...> - 2012-11-05 14:49:33
|
Hi Stanislav: Thanks for your patches. I used to have a JavaStation to test the big endian implementation, but that went to electronics recycling a long time ago. If you would be so kind as to send me your patches as separate attachments (or in a single tar file), I would appreciate it. Also, since I can't really test these patches on alpha, s390 or ARM, can I send you an updated libEMF source tar file for you to check? Thanks, Allen On Mon, Nov 5, 2012 at 8:53 AM, Stanislav Ochotnicky <soc...@re...> wrote: > Hi, > > we have recently encountered libEMF failures when compiling on ppc64 > architecture. This seemed to be introduced in libEMF-1.0.5 with conditionals > referencing x86_64 architecture directly instead of generic 64bit > architecture. I have created a patch (1/4) to fix this and reference __LP64__ > instead of __x86_64__. Next three patches add support for additional > architectures, most notably alpha, s390/s390x and arm. > > If you could include these changes in your next release, it would be > appreciated. > > If you'd like me to change these patches or explain details, let me know > > -- > Stanislav Ochotnicky <soc...@re...> > Software Engineer - Base Operating Systems Brno > > PGP: 7B087241 > Red Hat Inc. http://cz.redhat.co > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > _______________________________________________ > Libemf-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libemf-devel |
|
From: Stanislav O. <soc...@re...> - 2012-11-05 13:54:05
|
--- include/libEMF/wine/winnt.h | 67 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/include/libEMF/wine/winnt.h b/include/libEMF/wine/winnt.h index db36502..f76c08a 100644 --- a/include/libEMF/wine/winnt.h +++ b/include/libEMF/wine/winnt.h @@ -41,6 +41,10 @@ # undef WORDS_BIGENDIAN # undef BITFIELDS_BIGENDIAN # undef ALLOW_UNALIGNED_ACCESS +#elif defined(__arm__) +# undef WORDS_BIGENDIAN +# undef BITFIELDS_BIGENDIAN +# undef ALLOW_UNALIGNED_ACCESS #elif defined(__sparc__) # define WORDS_BIGENDIAN # define BITFIELDS_BIGENDIAN @@ -1358,6 +1362,69 @@ typedef struct _CONTEXT #endif /* __s390__ */ +#ifdef __arm__ + +/* These definitions are taken directly from wine + * http://source.winehq.org/git/wine.git/blob_plain/HEAD:/include/winnt.h */ + +/* The following flags control the contents of the CONTEXT structure. */ + +#define CONTEXT_ARM 0x0200000 +#define CONTEXT_CONTROL (CONTEXT_ARM | 0x00000001) +#define CONTEXT_INTEGER (CONTEXT_ARM | 0x00000002) +#define CONTEXT_FLOATING_POINT (CONTEXT_ARM | 0x00000004) +#define CONTEXT_DEBUG_REGISTERS (CONTEXT_ARM | 0x00000008) + +#define CONTEXT_FULL (CONTEXT_CONTROL | CONTEXT_INTEGER) + +#define EXCEPTION_READ_FAULT 0 +#define EXCEPTION_WRITE_FAULT 1 +#define EXCEPTION_EXECUTE_FAULT 8 + +typedef struct _CONTEXT { +/* The flags values within this flag control the contents of + * a CONTEXT record. + * + * If the context record is used as an input parameter, then + * for each portion of the context record controlled by a flag + * whose value is set, it is assumed that that portion of the + * context record contains valid context. If the context record + * is being used to modify a thread's context, then only that + * portion of the threads context will be modified. + * + * If the context record is used as an IN OUT parameter to capture + * the context of a thread, then only those portions of the thread's + * context corresponding to set flags will be returned. + * + * The context record is never used as an OUT only parameter. */ + +ULONG ContextFlags; + +/* This section is specified/returned if the ContextFlags word contains + * the flag CONTEXT_INTEGER. */ +ULONG R0; +ULONG R1; +ULONG R2; +ULONG R3; +ULONG R4; +ULONG R5; +ULONG R6; +ULONG R7; +ULONG R8; +ULONG R9; +ULONG R10; +ULONG Fp; +ULONG Ip; + +/* These are selected by CONTEXT_CONTROL */ +ULONG Sp; +ULONG Lr; +ULONG Pc; +ULONG Cpsr; +} CONTEXT; + +#endif /* __arm__ */ + #if !defined(CONTEXT_FULL) && !defined(RC_INVOKED) #error You need to define a CONTEXT for your CPU #endif -- 1.7.11.7 |
|
From: Stanislav O. <soc...@re...> - 2012-11-05 13:54:05
|
---
include/libEMF/wine/winnt.h | 90 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/include/libEMF/wine/winnt.h b/include/libEMF/wine/winnt.h
index 1418a4a..db36502 100644
--- a/include/libEMF/wine/winnt.h
+++ b/include/libEMF/wine/winnt.h
@@ -49,6 +49,10 @@
# define WORDS_BIGENDIAN
# define BITFIELDS_BIGENDIAN
# undef ALLOW_UNALIGNED_ACCESS
+#elif defined(__s390__)
+# define WORDS_BIGENDIAN
+# define BITFIELDS_BIGENDIAN
+# undef ALLOW_UNALIGNED_ACCESS
#elif !defined(RC_INVOKED)
# error Unknown CPU architecture!
#endif
@@ -1295,6 +1299,65 @@ typedef struct _CONTEXT
#endif /* __sparc__ */
+#ifdef __s390__
+
+/*
+ * FIXME:
+ *
+ * There is no official CONTEXT structure defined for the S390
+ * architecture, so I just made one up.
+ *
+ * Note that this structure contains only the 'top-level' registers;
+ * the rest of the register window chain is not visible.
+ *
+ * The layout is based on the sparc one.
+ *
+ */
+
+#define CONTEXT_S390C 0x20000000
+
+#define CONTEXT_CONTROL (CONTEXT_S390 | 0x00000001)
+#define CONTEXT_FLOATING_POINT (CONTEXT_S390 | 0x00000002)
+#define CONTEXT_INTEGER (CONTEXT_S390 | 0x00000004)
+
+#define CONTEXT_FULL (CONTEXT_CONTROL | CONTEXT_FLOATING_POINT | CONTEXT_INTEGER)
+
+typedef struct _CONTEXT
+{
+ DWORD ContextFlags;
+
+ /* These are selected by CONTEXT_INTEGER */
+ DWORD r0;
+ DWORD r1;
+ DWORD r2;
+ DWORD r3;
+ DWORD r4;
+ DWORD r5;
+ DWORD r6;
+ DWORD r7;
+ DWORD r8;
+ DWORD r9;
+ DWORD r10;
+ DWORD r11;
+ DWORD r12;
+ DWORD r13;
+ DWORD r14;
+ DWORD r15;
+
+ /* FIXME: this section is fictional (copied from sparc) */
+ DWORD psr;
+ DWORD pc;
+ DWORD npc;
+ DWORD y;
+ DWORD wim;
+ DWORD tbr;
+
+ /* FIXME: floating point registers missing */
+
+} CONTEXT;
+
+#endif /* __s390__ */
+
#if !defined(CONTEXT_FULL) && !defined(RC_INVOKED)
#error You need to define a CONTEXT for your CPU
#endif
@@ -1413,6 +1476,33 @@ typedef CONTEXT *PCONTEXT;
#endif /* __sparc__ */
+#ifdef __s390__
+/* FIXME: use getcontext() to retrieve full context */
+#define _GET_CONTEXT \
+ CONTEXT context; \
+ do { memset(&context, 0, sizeof(CONTEXT)); \
+ context.ContextFlags = CONTEXT_CONTROL; \
+ context.pc = (DWORD)__builtin_return_address(0); \
+ } while (0)
+
+#define DEFINE_REGS_ENTRYPOINT_0( name, fn ) \
+ void WINAPI name ( void ) \
+ { _GET_CONTEXT; fn( &context ); }
+#define DEFINE_REGS_ENTRYPOINT_1( name, fn, t1 ) \
+ void WINAPI name ( t1 a1 ) \
+ { _GET_CONTEXT; fn( a1, &context ); }
+#define DEFINE_REGS_ENTRYPOINT_2( name, fn, t1, t2 ) \
+ void WINAPI name ( t1 a1, t2 a2 ) \
+ { _GET_CONTEXT; fn( a1, a2, &context ); }
+#define DEFINE_REGS_ENTRYPOINT_3( name, fn, t1, t2, t3 ) \
+ void WINAPI name ( t1 a1, t2 a2, t3 a3 ) \
+ { _GET_CONTEXT; fn( a1, a2, a3, &context ); }
+#define DEFINE_REGS_ENTRYPOINT_4( name, fn, t1, t2, t3, t4 ) \
+ void WINAPI name ( t1 a1, t2 a2, t3 a3, t4 a4 ) \
+ { _GET_CONTEXT; fn( a1, a2, a3, a4, &context ); }
+
+#endif /* __s390__ */
+
#ifdef __PPC__
/* FIXME: use getcontext() to retrieve full context */
--
1.7.11.7
|
|
From: Stanislav O. <soc...@re...> - 2012-11-05 13:53:59
|
--- include/libEMF/wine/winnt.h | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/include/libEMF/wine/winnt.h b/include/libEMF/wine/winnt.h index 51075f4..1418a4a 100644 --- a/include/libEMF/wine/winnt.h +++ b/include/libEMF/wine/winnt.h @@ -37,6 +37,10 @@ # undef WORDS_BIGENDIAN # undef BITFIELDS_BIGENDIAN # define ALLOW_UNALIGNED_ACCESS +#elif defined(__alpha__) +# undef WORDS_BIGENDIAN +# undef BITFIELDS_BIGENDIAN +# undef ALLOW_UNALIGNED_ACCESS #elif defined(__sparc__) # define WORDS_BIGENDIAN # define BITFIELDS_BIGENDIAN @@ -238,7 +242,7 @@ typedef unsigned short WORD, *PWORD, *LPWORD; typedef int INT, *PINT, *LPINT; typedef unsigned int UINT, *PUINT, *LPUINT; /* Not sure this is correct. Probably should depend on the compiler, too. */ -#if defined( __LP64__) +#if defined( __LP64__) || defined(__alpha__) typedef unsigned int DWORD, *PDWORD, *LPDWORD; typedef unsigned int ULONG, *PULONG, *LPULONG; #else @@ -284,7 +288,7 @@ typedef VOID *PVOID, *LPVOID; typedef BYTE BOOLEAN, *PBOOLEAN; typedef char CHAR, *PCHAR; typedef short SHORT, *PSHORT; -#if defined(__LP64__) +#if defined(__LP64__) || defined(__alpha__) typedef int LONG, *PLONG, *LPLONG; #else typedef long LONG, *PLONG, *LPLONG; @@ -897,7 +901,7 @@ PVOID WINAPI RtlVirtualUnwind(ULONG,ULONG64,ULONG64,RUNTIME_FUNCTION #endif /* __x86_64__ */ /* Alpha context definitions */ -#ifdef _ALPHA_ +#if defined(__alpha__) #define CONTEXT_ALPHA 0x00020000 -- 1.7.11.7 |
|
From: Stanislav O. <soc...@re...> - 2012-11-05 13:53:58
|
---
include/libEMF/wine/winnt.h | 4 ++--
libemf/libemf.h | 54 ++++++++++++++++++++++-----------------------
2 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/include/libEMF/wine/winnt.h b/include/libEMF/wine/winnt.h
index b4e9a1d..51075f4 100644
--- a/include/libEMF/wine/winnt.h
+++ b/include/libEMF/wine/winnt.h
@@ -238,7 +238,7 @@ typedef unsigned short WORD, *PWORD, *LPWORD;
typedef int INT, *PINT, *LPINT;
typedef unsigned int UINT, *PUINT, *LPUINT;
/* Not sure this is correct. Probably should depend on the compiler, too. */
-#if defined( __x86_64__)
+#if defined( __LP64__)
typedef unsigned int DWORD, *PDWORD, *LPDWORD;
typedef unsigned int ULONG, *PULONG, *LPULONG;
#else
@@ -284,7 +284,7 @@ typedef VOID *PVOID, *LPVOID;
typedef BYTE BOOLEAN, *PBOOLEAN;
typedef char CHAR, *PCHAR;
typedef short SHORT, *PSHORT;
-#if defined(__x86_64__)
+#if defined(__LP64__)
typedef int LONG, *PLONG, *LPLONG;
#else
typedef long LONG, *PLONG, *LPLONG;
diff --git a/libemf/libemf.h b/libemf/libemf.h
index a376150..9497b6d 100644
--- a/libemf/libemf.h
+++ b/libemf/libemf.h
@@ -340,7 +340,7 @@ namespace EMF {
fread( &dword, sizeof(DWORD), 1, fp_ );
return *this;
}
-#if !defined( __x86_64__ )
+#if !defined( __LP64__ )
/*!
* Output a long int to the stream (swabbed).
* \param long long int to output.
@@ -410,7 +410,7 @@ namespace EMF {
fread( &int_, sizeof(INT), 1, fp_ );
return *this;
}
-#if !defined(__x86_64__)
+#if !defined(__LP64__)
/*!
* Output a (long) unsigned int to the stream (swabbed).
* \param uint (long) unsigned int to output.
@@ -985,7 +985,7 @@ namespace EMF {
/* Miscellaneous editing routines */
inline void edit_rectl ( const char* tag, const RECTL& rectl )
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "\t%s\t: (%d, %d) - (%d, %d)\n";
#else
const char* FMT = "\t%s\t: (%ld, %ld) - (%ld, %ld)\n";
@@ -1005,7 +1005,7 @@ namespace EMF {
inline void edit_color ( const char* tag, const COLORREF& color )
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "\t%s\t: R(0x%02x) G(0x%02x) B(0x%02x)\n";
#else
const char* FMT = "\t%s\t: R(0x%02lx) G(0x%02lx) B(0x%02lx)\n";
@@ -1016,7 +1016,7 @@ namespace EMF {
inline void edit_sizel ( const char* tag, const SIZEL& size )
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "\t%s\t: (%d, %d)\n";
#else
const char* FMT = "\t%s\t: (%ld, %ld)\n";
@@ -1026,7 +1026,7 @@ namespace EMF {
inline void edit_pointl ( const char* tag, const POINTL& point )
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "\t%s\t: (%d, %d)\n";
#else
const char* FMT = "\t%s\t: (%ld, %ld)\n";
@@ -1037,7 +1037,7 @@ namespace EMF {
inline void edit_pointlarray ( const char* tag, const DWORD cptl,
const POINTL* points )
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT0 = "\tcptl%s\t: %d\n";
const char* FMT1 = "%d, %d\n";
const char* FMT2 = "\t\t%s %d, %d\n";
@@ -1102,7 +1102,7 @@ namespace EMF {
inline void edit_brush_style ( const char* tag, DWORD style )
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "unknown(%d)";
#else
const char* FMT = "unknown(%ld)";
@@ -1126,7 +1126,7 @@ namespace EMF {
inline void edit_brush_hatch ( const char* tag, DWORD hatch )
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "unknown(%d)";
#else
const char* FMT = "unknown(%ld)";
@@ -1473,7 +1473,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT0 = "\tiType\t\t\t: %d\n";
const char* FMT1 = "\tnSize\t\t\t: %d\n";
const char* FMT2 = "\tnBytes\t\t\t: %d\n";
@@ -1855,7 +1855,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT0 = "\txNum\t: %d\n";
const char* FMT1 = "\txDenom\t: %d\n";
const char* FMT2 = "\tyNum\t: %d\n";
@@ -1993,7 +1993,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT0 = "\txNum\t: %d\n";
const char* FMT1 = "\txDenom\t: %d\n";
const char* FMT2 = "\tyNum\t: %d\n";
@@ -2069,7 +2069,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "unknown(%d)\n";
#else
const char* FMT = "unknown(%ld)\n";
@@ -2196,7 +2196,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "| unknown bits(0x%x)";
#else
const char* FMT = "| unknown bits(0x%lx)";
@@ -2394,7 +2394,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "unknown(%d)\n";
#else
const char* FMT = "unknown(%ld)\n";
@@ -2460,7 +2460,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "unknown(%d)\n";
#else
const char* FMT = "unknown(%ld)\n";
@@ -2527,7 +2527,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "unknown(%d)\n";
#else
const char* FMT = "unknown(%ld)\n";
@@ -2596,7 +2596,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "\tihObject\t: 0x%x\n";
#else
const char* FMT = "\tihObject\t: 0x%lx\n";
@@ -2654,7 +2654,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "\tihObject\t: 0x%x\n";
#else
const char* FMT = "\tihObject\t: 0x%lx\n";
@@ -3580,7 +3580,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT0 = "\tnPolys\t\t: %d\n";
const char* FMT1 = "\tcptl\t\t: %d\n";
const char* FMT2 = "%d\n";
@@ -3770,7 +3770,7 @@ namespace EMF {
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT0 = "\tnPolys\t\t: %d\n";
const char* FMT1 = "\tcptl\t\t: %d\n";
const char* FMT2 = "%d\n";
@@ -4575,7 +4575,7 @@ For pstoedit - this is "fixed" now by estimating dx in pstoedit
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT0 = "unknown(%d)\n";
const char* FMT1 = "\tptlReference\t: (%d,%d)\n";
const char* FMT2 = "\tnChars\t\t: %d\n";
@@ -4759,7 +4759,7 @@ For pstoedit - this is "fixed" now by estimating dx in pstoedit
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT0 = "\tihPen\t\t: 0x%x\n";
const char* FMT1 = "\tlopn.lopnWidth\t: %d, %d\n";
#else
@@ -4817,7 +4817,7 @@ For pstoedit - this is "fixed" now by estimating dx in pstoedit
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT0 = "\tihPen\t\t\t: 0x%x\n";
const char* FMT1 = "\toffBmi\t\t\t: %d\n";
const char* FMT2 = "\tcbBmi\t\t\t: %d\n";
@@ -4891,7 +4891,7 @@ For pstoedit - this is "fixed" now by estimating dx in pstoedit
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "\tihBrush\t\t: 0x%x\n";
#else
const char* FMT = "\tihBrush\t\t: 0x%lx\n";
@@ -4951,7 +4951,7 @@ For pstoedit - this is "fixed" now by estimating dx in pstoedit
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT0 = "\tihFont\t\t\t: %d\n";
const char* FMT1 = "\tlfHeight\t\t: %d\n";
const char* FMT2 = "\tlfWidth\t\t\t: %d\n";
@@ -5520,7 +5520,7 @@ For pstoedit - this is "fixed" now by estimating dx in pstoedit
*/
void edit ( void ) const
{
-#if defined(__x86_64__)
+#if defined(__LP64__)
const char* FMT = "\tiRelative: %d\n";
#else
const char* FMT = "\tiRelative: %ld\n";
--
1.7.11.7
|
|
From: Stanislav O. <soc...@re...> - 2012-11-05 13:53:57
|
Hi, we have recently encountered libEMF failures when compiling on ppc64 architecture. This seemed to be introduced in libEMF-1.0.5 with conditionals referencing x86_64 architecture directly instead of generic 64bit architecture. I have created a patch (1/4) to fix this and reference __LP64__ instead of __x86_64__. Next three patches add support for additional architectures, most notably alpha, s390/s390x and arm. If you could include these changes in your next release, it would be appreciated. If you'd like me to change these patches or explain details, let me know -- Stanislav Ochotnicky <soc...@re...> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.co |
|
From: Allen B. <all...@gm...> - 2012-05-24 15:59:47
|
That was quick; here is 1.0.6. Nothing like making a change to excite additional bugs. The SetMiterLimit API takes a float, but the integer version is stored in the metafile. Thanks, Allen |
|
From: Allen B. <all...@gm...> - 2012-05-24 13:20:38
|
If anybody is listening (and cares) I added the API for the SetMiterLimit record to libEMF. Apparently, the Inkscape EMF interface uses that function. I released libEMF 1.0.5. This was as much to refresh my SourceForge skills as anything else. Thanks, Allen |
|
From: Allen B. <all...@gm...> - 2011-11-02 15:12:58
|
Hi Chaitanya: I just tried to build libEMF on a Ubuntu 9.10 64-bit system and it would not compile. I guess the GCC on the system does not define the correct macros that the fake-windows headers are expecting. I got mostly through the build with: $ CFLAGS="-D__i386__" CXXFLAGS="-D__i386__" configure $ make $ make check However, all the check tests failed; so I suspect that there are more problems with 64-bits. I don't have a 32-bit Ubuntu system to test on. I would recommend that you try to install the pstoedit tool. That software has an windows metafile output driver which uses libEMF. If someone has built pstoedit on Ubuntu, then possibly they built libEMF as well. (Anyway, on Fedora, you get libEMF when you install pstoedit.) Allen On Wed, 2011-11-02 at 19:29 +0530, chaitanya prasad movva wrote: > Hi, > Can i please get some compilation instructions to compile LIBEMF on > Ubuntu. > > Regards, > Chaitanya |
|
From: chaitanya p. m. <cha...@gm...> - 2011-11-02 13:59:31
|
Hi,
Can i please get some compilation instructions to compile LIBEMF on
Ubuntu.
Regards,
Chaitanya
|
|
From: Allen B. <al...@tr...> - 2010-12-06 14:31:35
|
Basically: Is this functioning now? -- Allen |
|
From: Allen B. <al...@tr...> - 2010-12-06 14:26:48
|
Is the mailing list working now? I suppose so. -- Allen Barnett Transpire, Inc E-Mail: al...@tr... |
|
From: lI <lux...@bt...> - 2010-07-15 21:30:52
|
Greetings,
I have attempted to compile limEMF-1.0.4 on an x86_64-based computer running
64-bit linux (kernel2.6.34, gcc-2.6.34). The compiler output is below:-
###########
make[1]: Entering directory `/home/ruler/build10u2/sources-
analog18210/fppAn18210/libEMF-1.0.4/libemf'
/bin/sh /usr/bin/libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -
I../config -I../include -g -O2 -D_REENTRANT -DPTHREADS -MT libemf.lo -MD -MP
-MF .deps/libemf.Tpo -c -o libemf.lo libemf.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../config -I../include -g -O2 -
D_REENTRANT -DPTHREADS -MT libemf.lo -MD -MP -MF .deps/libemf.Tpo -c
libemf.cpp -fPIC -DPIC -o .libs/libemf.o
In file included from ../include/libEMF/wine/windef.h:16,
from ../include/libEMF/emf.h:27,
from libemf.h:31,
from libemf.cpp:24:
../include/libEMF/wine/winnt.h:45:3: error: #error Unknown CPU architecture!
../include/libEMF/wine/winnt.h:1051:2: error: #error You need to define a
CONTEXT for your CPU
In file included from ../include/libEMF/wine/windef.h:16,
from ../include/libEMF/emf.h:27,
from libemf.h:31,
from libemf.cpp:24:
../include/libEMF/wine/winnt.h:1054: error: expected initializer before '*'
token
../include/libEMF/wine/winnt.h:2294: error: 'PCONTEXT' does not name a type
../include/libEMF/wine/winnt.h:2307: error: 'PCONTEXT' has not been declared
In file included from ../include/libEMF/emf.h:28,
from libemf.h:31,
from libemf.cpp:24:
../include/libEMF/wine/winbase.h:120: error: 'PCONTEXT' does not name a type
In file included from ../include/libEMF/emf.h:28,
from libemf.h:31,
from libemf.cpp:24:
../include/libEMF/wine/winbase.h:1243: error: 'CONTEXT' has not been declared
../include/libEMF/wine/winbase.h:1377: error: ISO C++ forbids declaration of
'CONTEXT' with no type
../include/libEMF/wine/winbase.h:1377: error: expected ',' or '...' before '*'
token
make[1]: *** [libemf.lo] Error 1
###################
help by way of patches/suggested edits or suggested URL's for code where
these are fixed will be appreciated.
Yours sincerely
luxInteg
|
|
From: <Mat...@sn...> - 2006-03-16 07:45:57
|
Hi all As my mailaddress for Allen Barnett is no longer right, I try the libemf list. Are there any news about libemf or is it dead? Thanks for an answer to my direct Mail. Regards Matthias ----- Forwarded by Matthias Dillier/SNB on 16.03.2006 08:43 ----- Matthias Dillier/SNB 15.03.2006 14:42 To Allen Barnett <al...@li...> cc Subject Re: EMF-driver for Grace Hi Allen How are you and your family? Any news/plans for libemf or is it dead? Regards and have a nice day Matthias Allen Barnett <al...@li...> wrote on 10.12.2003 14:57:57: > Hi Matthias, > > I'm now working full time for a new company and our first software release is > scheduled for January, 2004. > > Also, we're expecting our first child in February. So, between the > two, all of > my time, free, spare or otherwise, is completely consumed for the next few > months. > > I'm also dissolving lignum Computing, Inc. at the end of the month. The State > of New York, USA, is octupling the franchise tax for 2004, so it makes no > fiscal sense to continue to operate. > > I'm sorry that I don't have better news for you. > > Allen > > On Wednesday 10 December 2003 08:37, you wrote: > > Hi Allen > > > > Sorry to disturb you again. Any ideas when you could enhance the emf-driver > > for Grace? > > > > Regards, > > Matthias > > > > Allen Barnett <al...@ra...> wrote on 24.07.2003 16:20:00: > > > Hi Matthias, > > > > > > Fortunately (for me), the paying work keeps coming in so I haven't > > > had much of > > > a chance to work on anything else. I'm working with a startup company > > > > now, so > > > > > I have no idea when I'll be able to get back the EMF stuff. I'll try to > > > > keep > > > > > it mind, though. > > > > > > Allen > > > > > > On Thursday 24 July 2003 10:05 am, you wrote: > > > > Hi Allen > > > > > > > > Any good news about additions to the EMF-driver for Grace? > > > > > > > > Regards, > > > > Matthias > > > > This message is for information purposes only. It may not be secure or > > error-free. The Swiss National Bank does not accept legal responsibility > > for any consequences resulting from e-mail use. > This message is for information purposes only. It may not be secure or error-free. The Swiss National Bank does not accept legal responsibility for any consequences resulting from e-mail use. |
|
From: Fredrik S. <fre...@gl...> - 2005-04-12 16:05:40
|
I get the following error when trying to make the libEMF package on my RedHat Linux box. Does anybody know what I need to do to resolve the issue? g++ -DHAVE_CONFIG_H -I. -I. -I../config -I../include -g -O2 -D_REENTRANT = -DPTHREADS -c libemf.cpp -MT libemf.lo -MD -MP -MF .deps/libemf.TPlo = -fPIC -DPIC -o .libs/libemf.lo libemf.cpp: In static member function `static bool=20 EMF::DATASTREAM::bigEndian()': libemf.cpp:51: `cerr' undeclared (first use this function) libemf.cpp:51: (Each undeclared identifier is reported only once for = each=20 function it appears in.) libemf.cpp:51: `endl' undeclared (first use this function) /Fredrik |
|
From: Christoph L. <Christoph.Lindemann@PrintAssociates.com> - 2004-06-17 12:03:40
|
Hi All, Just want to let you know that I have published information about some of the undocumented EMF records on the following website. http://undocprint.printassociates.com/ If you have any comments or questions, please feel free to contact me. Best regards, Christoph Lindemann |
2455 messages has been excluded from this view by a project administrator.