pyx-devel — PyX development

Re: [PyX-devel] [PATCH 2/2] arrow: make pos relative to the full arclength

[Joerg L. <jo...@us...>]

Hi Michael,

Thanks for the patch. I am not sure, however, whether it really improves
the situation. In particular, I do not like the fact that varying the
pos argument at the beginning and end of the path does not move the
arrow at all. If I understand the intention of the change correctly, it
means that the arrow is always positioned at the end of the
constriction - as long as this is possible. Why is this desirable?

Cheers,

        Jörg


On 11.05.12, Michael J Gruber wrote:
> To make it clearer what this is about, here's some before and after
> comparison:
> 
> https://github.com/mjg/PyX/wiki/Arrow-Heads
> 
> Cheers
> Michael
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> PyX-devel mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel
> 

Re: [PyX-devel] [PATCH 2/2] arrow: make pos relative to the full arclength

[Michael J G. <mic...@us...>]

To make it clearer what this is about, here's some before and after
comparison:

https://github.com/mjg/PyX/wiki/Arrow-Heads

Cheers
Michael

[PyX-devel] [PATCH 2/2] arrow: make pos relative to the full arclength

[Michael J G. <mic...@us...>]

Currently, pos is relative to (arclength - constrictionlen) which makes
it very hard to position arrow heads correctly at, say, quarter circles etc.

Make it relative to the full arclength to ease positioning of the
arrow heads. This requires putting in a safeguard (so that arrow heads
do no come out before nor after that path) which may be of independent
interest.

Signed-off-by: Michael J Gruber <mic...@us...>
---
 pyx/deco.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/pyx/deco.py b/pyx/deco.py
index 2231899..84ae7f0 100644
--- a/pyx/deco.py
+++ b/pyx/deco.py
@@ -472,7 +472,8 @@ class arrow(deco, attr.attr):
             constrictionlen = self.size * 1 * math.cos(math.radians(self.angle/2.0))
             arrowheadconstrictionlen = None
 
-        arclenfrombegin = (1-2*self.reversed)*constrictionlen + self.pos * (anormpath.arclen() - constrictionlen)
+        arclenfrombegin = (1-2*self.reversed)*constrictionlen + self.pos * anormpath.arclen()
+        arclenfrombegin = min(anormpath.arclen(), max(0, arclenfrombegin))
         direction = self.reversed and -1 or 1
         arrowhead = _arrowhead(anormpath, arclenfrombegin, direction, self.size, self.angle, arrowheadconstrictionlen)
 
-- 
1.7.10.1.702.g60a8c8a

[PyX-devel] [PATCH 1/2] arrow: position reversed arrow correctly

[Michael J G. <mic...@us...>]

r3151 took into account the direction already but missed the fact that
arrows are positioned wrt. the constriction center now. Make it so that
a reversed arrow is positioned wrt. the constriction center also.

Signed-off-by: Michael J Gruber <mic...@us...>
---
 pyx/deco.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pyx/deco.py b/pyx/deco.py
index 8cc6f95..2231899 100644
--- a/pyx/deco.py
+++ b/pyx/deco.py
@@ -472,7 +472,7 @@ class arrow(deco, attr.attr):
             constrictionlen = self.size * 1 * math.cos(math.radians(self.angle/2.0))
             arrowheadconstrictionlen = None
 
-        arclenfrombegin = (1-self.reversed)*constrictionlen + self.pos * (anormpath.arclen() - constrictionlen)
+        arclenfrombegin = (1-2*self.reversed)*constrictionlen + self.pos * (anormpath.arclen() - constrictionlen)
         direction = self.reversed and -1 or 1
         arrowhead = _arrowhead(anormpath, arclenfrombegin, direction, self.size, self.angle, arrowheadconstrictionlen)
 
-- 
1.7.10.1.702.g60a8c8a

Re: [PyX-devel] PyX-devel Digest, Vol 22, Issue 1

[André W. <wo...@us...>]

Hi,

I would take a look. Can you post it somewhere? You could also just sent some small code examples to this list.

Best,


André


Am 09.05.2012 um 15:49 schrieb José María Miotto:

> Hi to all.
> 
> I'm a user of PyX, and I had to make some Box Charts some weeks ago. So, I coded a simple style for pyx, and I'd like to share it with you. How do we proceed?
> 
> best regards,
> Jose
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> PyX-devel mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] PyX-devel Digest, Vol 22, Issue 1

[José M. M. <jos...@gm...>]

Hi to all.

I'm a user of PyX, and I had to make some Box
Charts<http://en.wikipedia.org/wiki/Box_plot>some weeks ago. So, I
coded a simple style for pyx, and I'd like to share
it with you. How do we proceed?

best regards,
Jose

[PyX-devel] [ pyx-Bugs-3524174 ] Mathjax error at online PyX Reference Manual

[SourceForge.net <no...@so...>]

Bugs item #3524174, was opened at 2012-05-06 15:22
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=3524174&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jeff Higgins (oohiggins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mathjax error at online PyX Reference Manual

Initial Comment:
When I access any pages at the PyX online Reference Manual
an error message popup is displayed, the text of the error message follows:

MathJax no longer loads a default configuration file; you must specify such files explicitly. This page seems to use the older default config/MathJax.js file, and so needs to be updated. This is explained further at

http://www.mathjax.org/help/configuration

It seems there is nothing I can do as a reader of the manual, only the author of the pages can fix this.  It is distracting.

Thanks
Jeff Higgins


----------------------------------------------------------------------

>Comment By: Andre Wobst (wobsta)
Date: 2012-05-08 16:54

Message:
Thanks for the report. I uploaded a new version.

Special thanks goes to Michael J Gruber for investigating the issue and
suggesting a patch to the build config to resolve the issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=3524174&group_id=45430

[PyX-devel] [PATCH 2/2] switch to the CDN version of MathJax

[Michael J G. <mic...@us...>]

It provides MathJax as a web service in a distributed cloud.

Signed-off-by: Michael J Gruber <mic...@us...>
---
 manual/conf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/manual/conf.py b/manual/conf.py
index 30e12e5..b4d4127 100644
--- a/manual/conf.py
+++ b/manual/conf.py
@@ -226,5 +226,5 @@ man_pages = [
 
 # -- Other options  ------------------------------------------------------------
 
-mathjax_path = 'http://mathjax.connectmv.com/MathJax.js?config=default'
+mathjax_path = 'http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=default'
 todo_include_todos = True
-- 
1.7.10.1.702.g60a8c8a

[PyX-devel] [PATCH 1/2] adjust to MathJax 1.1 configuration mechanism

[Michael J G. <mic...@us...>]

see http://www.mathjax.org/help/configuration/

Signed-off-by: Michael J Gruber <mic...@us...>
---
 manual/conf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/manual/conf.py b/manual/conf.py
index 9b0b4f5..30e12e5 100644
--- a/manual/conf.py
+++ b/manual/conf.py
@@ -226,5 +226,5 @@ man_pages = [
 
 # -- Other options  ------------------------------------------------------------
 
-mathjax_path = 'http://mathjax.connectmv.com/MathJax.js'
+mathjax_path = 'http://mathjax.connectmv.com/MathJax.js?config=default'
 todo_include_todos = True
-- 
1.7.10.1.702.g60a8c8a

[PyX-devel] [ pyx-Bugs-3524174 ] Mathjax error at online PyX Reference Manual

[SourceForge.net <no...@so...>]

Bugs item #3524174, was opened at 2012-05-06 15:22
Message generated for change (Tracker Item Submitted) made by oohiggins
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=3524174&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jeff Higgins (oohiggins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mathjax error at online PyX Reference Manual

Initial Comment:
When I access any pages at the PyX online Reference Manual
an error message popup is displayed, the text of the error message follows:

MathJax no longer loads a default configuration file; you must specify such files explicitly. This page seems to use the older default config/MathJax.js file, and so needs to be updated. This is explained further at

http://www.mathjax.org/help/configuration

It seems there is nothing I can do as a reader of the manual, only the author of the pages can fix this.  It is distracting.

Thanks
Jeff Higgins


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=3524174&group_id=45430

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3240] trunk/pyx/pyx/pswriter.py

[Joerg L. <jo...@us...>]

Hi,

On 18.02.12, André Wobst wrote:
> Hi Jörg,
> 
> Am 17.02.2012 um 10:57 schrieb Joerg Lehmann:
> >> In the end, I do not see why the registry -- it is not a general
> >> registry but a PSregistry -- should not contain PS-specific code like
> >> the DSC. We already have similar code in PSdefinition.
> > 
> > Simply because it is too specific. We could, however,
> > add more generic code to allow for adding sections in the first DSC
> > section.
> 
> 
> While I do see some problems in the Font-DSCs Michael just added, I do support to add DSCs via the registry. The reason is, that DSCs are (to some extend) resource descriptions collected from all the components of the file. There are DSCs (we do not yet support), which are crucial. I remember one (old) use-case where I had to add DSCs, which had been collected from included EPS files (this was related to spot colors). At that point in time we didn't had such a fancy infrastructure like the registry and in the end of the day my solution was to add another "walk-through-all-the-content-to-collect-some-data" like what we're did for the bounding box.

But that is pretty much what I meant with "more generic code". 

> Please consider the font DSCs as a initial and specific solution for a
> general DSC-handling which surely should be handled via the registry.
> The details of this functionality has to be developed, but in general
> (to my current understanding) it is correct to use the registry here.

Ok. I just did not like the very specific usage - but that was mainly a
question of taste.

> (Still I think the font-DSCs Michael proposed in this thread are wrong, but this is a different issue.)

I mainly saw the problem that we need to also include all resources used
in EPS files we include ourselves. This requires parsing the DSC of
those files to some degree. At the time when I wrote the PS output code,
this seemed some way to go and that's why I only marked the omission of
the corresponding DSCs in a comment.

Cheers,

        Jörg

Re: [PyX-devel] Missing glyphs when including PyX files

[André W. <wo...@us...>]

Hi Michael,

in general there's nothing wrong about adding DSCs, far from it. However, stripped fonts should neither be listed in DocumentSuppliedFonts (they are incomplete) nor in DocumentNeededFonts (they are embedded and thus not needed). (And I know that there are newer DSC names like DocumentSuppliedResources, but this is not important for this discussion.) Furthermore I'm sure we should use the registry to handle DSCs. We don't do anything at all in this direction so far (and maybe we'll never add it), but it is the proper infrastructure. As I told you in my other email I was asked to add some DSC handling for some special project and it was ugly as we didn't had the registry at that time. In this project I did not only needed to collect DSC data from own canvasitems, but also from included EPS files. The DSC infrastructure should collect DSCs from embedded EPS file and "forward" it to the outside document. We don't do anything like that at the moment, but I just wanted to give you an impression of what could be done.

Best,


André

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] Missing glyphs when including PyX files

[Michael S. <m-s...@us...>]

Salut André,

On 18/02/12, André Wobst wrote:
> However, it is interesting to note, that this is a rather new issue.
> To my understanding it is related to recent changes in the type1
> computer modern fonts I observed elsewhere (see
> http://sourceforge.net/mailarchive/forum.php?thread_name=4E95F322.70505%40users.sourceforge.net&forum_name=pyx-devel).

Yes, I remember that comment, but did not follow closely.

> When you use latex and dvips on this later file and you have the new
> versions of the computer modern type1 fonts installed, the glyph a
> is not displayed in the output even though it is contained in the
> postscript file. There is something wrong in the postscript file,
> and it has nothing to do with the DSCs. (You can remove all DSCs and
> the problem remains.) Your DSC commands will result in the embedding
> of full font (without stripping) by dvips. This is not needed and
> not correct.

Have many thanks for the thorough analysis. You convinced me that it
is not a DSC issue.

> 2. Consider the case that you use a font in the figure, which you do
> not use in the document. Inserting the DSCs you suggested will
> result in the full embedding of the font in the "outside" document
> for no valid reason at all. This is due to the fact that dvips
> "thinks" that those font informations you mark in the DSCs are
> "DocumentNeededFonts"-entries. This is wrong, we properly embed all
> the fonts.

OK, you are right. I will undo the changes in pswriter.

> We basically do have two options to address this bug directly.
> 
> 1. We could clear all font information in the beginning of the PyX
> Postscript files by the following small code: "(*) {undefinefont}
> 128 string /Font resourceforall" – as I suggested in July last year
> already. But that time I suggested it as a patch to dvips (in
> special.pro). However, we could move it on top of your PyX
> Postscript output too. This is rather trivial to do. Just insert
> this line prior to the font resources in the eps files of the
> figures (for example immediately after the %%BeginProlog DSC) and
> the whole issue goes away.
> 
> 2. We could remove the fancy search for a font with the same
> UniqueID from the fonts we embed in our Postscript output. Not
> difficult either. I suggest to go for the second option. See
> changeset 3242 for the implementation.

So, it was the "{restore} if" (and a bit more) which I suspected in
the beginning, whithout really knowing what it was. You seem to speak
postscript quite fluently!
I also opt for the second solution, although it is worth keeping the
other in mind for the case one has to fix a given eps file by hand --
one never knows ...

Michael

Re: [PyX-devel] Missing glyphs when including PyX files

[André W. <wo...@us...>]

Hi Michael,

Am 18.02.2012 um 11:41 schrieb Michael SCHINDLER:
> As I see things, there are other (broken) programs, such as dvips and
> the software at SoftMatter journal, which require them. If we add
> standard-conforming DSC, we do nothing wrong and avoid a lot of
> nuisence on PyX-users' side.

You're absolutely right (and I somehow missed it in the earlier discussion, that this is an unacceptable situation. eps files created by PyX should work with dvips properly, and they currently do not do that.

However, it is interesting to note, that this is a rather new issue. To my understanding it is related to recent changes in the type1 computer modern fonts I observed elsewhere (see http://sourceforge.net/mailarchive/forum.php?thread_name=4E95F322.70505%40users.sourceforge.net&forum_name=pyx-devel).

>> However and first of all, we should *not* write a
>> DocumentSuppliedFonts DSC if we include a stripped version of a font
>> only.
> 
> I do see your point. But does "DocumentSuppliedFonts" mean that these
> fonts are complete?

Yeah, I would say so. Otherwise this statement, that such a resource is included (incomplete) is rather pointless.

>> Furthermore the DocumentSuppliedFonts is not responsible for
>> the "fix" you observe then using dvips. Instead, it is the
>> DocumentFonts DSC. But this directive is an older and deprecated
>> DSC. It was replaced by DocumentSuppliedFonts and
>> DocumentNeededFonts. The DocumentFonts should contain all fonts
>> listed in both, the DocumentSuppliedFonts and DocumentNeededFonts
>> DSCs.
> 
> This is what I erroneously claimed in one of my previous mails. I read
> again, and now I understand that all three DocumentXXXFonts are
> deprecated and should be written as DocumentXXXResources. I
> nevertheless kept the DocumentXXXFonts because our T1fonts are
> declared in DSC as "BeginFont ... EndFont" and not as Resources.

To my mind it doesn't matter at all. It is not a DSC issue at all.

> So, you propose to keep the old version?

Yes, we do not need any DSC entries. The problem is completely independent of that. Let me give you two examples, why this whole discussion leads us into the wrong direction (to my mind).

1. Consider this kind of minimal example:

    from pyx import *

    c = canvas.canvas()
    c.text(0,0,"a")
    c.writeEPSfile("fig")

and then the following latex file:

    \documentclass{article}
    \usepackage{graphicx}
    \begin{document}
    \includegraphics{fig}
    b
    \end{document}

When you use latex and dvips on this later file and you have the new versions of the computer modern type1 fonts installed, the glyph a is not displayed in the output even though it is contained in the postscript file. There is something wrong in the postscript file, and it has nothing to do with the DSCs. (You can remove all DSCs and the problem remains.) Your DSC commands will result in the embedding of full font (without stripping) by dvips. This is not needed and not correct.

2. Consider the case that you use a font in the figure, which you do not use in the document. Inserting the DSCs you suggested will result in the full embedding of the font in the "outside" document for no valid reason at all. This is due to the fact that dvips "thinks" that those font informations you mark in the DSCs are "DocumentNeededFonts"-entries. This is wrong, we properly embed all the fonts.

> I strongly disagree, as these
> problems occur far too often.

You're right (as I wrote in the beginning of this email already). We can not ignore this issue. As I said I was not aware of its generic nature. Still the real reason is that the new versions of the computer modern type1 fonts do some fancy search for a font with the same UniqueID being already defined and dvips failing to remove the UniqueID when stripping the font (which is clearly a bug).

We basically do have two options to address this bug directly.

1. We could clear all font information in the beginning of the PyX Postscript files by the following small code: "(*) {undefinefont} 128 string /Font resourceforall" – as I suggested in July last year already. But that time I suggested it as a patch to dvips (in special.pro). However, we could move it on top of your PyX Postscript output too. This is rather trivial to do. Just insert this line prior to the font resources in the eps files of the figures (for example immediately after the %%BeginProlog DSC) and the whole issue goes away.

2. We could remove the fancy search for a font with the same UniqueID from the fonts we embed in our Postscript output. Not difficult either. I suggest to go for the second option. See changeset 3242 for the implementation.

Best,


André

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] Missing glyphs when including PyX files

[Michael S. <m-s...@us...>]

Hello André,

On 18/02/12, André Wobst wrote:
> First of all DSC-comments should be optional in almost all cases.
> Like this one here. We should not need those comments. They are not
> required. They can be used for resource management to prevent
> resources to be included several times in a combined postscript
> file.

As I see things, there are other (broken) programs, such as dvips and
the software at SoftMatter journal, which require them. If we add
standard-conforming DSC, we do nothing wrong and avoid a lot of
nuisence on PyX-users' side.

> However and first of all, we should *not* write a
> DocumentSuppliedFonts DSC if we include a stripped version of a font
> only.

I do see your point. But does "DocumentSuppliedFonts" mean that these
fonts are complete? A look into the postscript books
(Reference_3Edition.pdf, 5001.DSC_Spec.pdf, T1_SPEC.PDF) does not
elucidate: I cannot find any comment on partial fonts. The closest is
in the DSC standard:

   A document-producing application should almost always use the same
   prolog for all of its documents, or at least the prolog should be
   drawn from a pool of common procedure sets. The prolog should always
   be constructed in a way that it can be removed from the document and
   downloaded only once into the printer. All subsequent documents that
   are downloaded with this prolog stripped out should still execute
   correctly.

AS the font resources are in the prolog, this would mean that the same
prolog should apply for a bunch of files. So, the first file must
contain all fonts used in the later. This is probably not what they
have in mind.

> Furthermore the DocumentSuppliedFonts is not responsible for
> the "fix" you observe then using dvips. Instead, it is the
> DocumentFonts DSC. But this directive is an older and deprecated
> DSC. It was replaced by DocumentSuppliedFonts and
> DocumentNeededFonts. The DocumentFonts should contain all fonts
> listed in both, the DocumentSuppliedFonts and DocumentNeededFonts
> DSCs.

This is what I erroneously claimed in one of my previous mails. I read
again, and now I understand that all three DocumentXXXFonts are
deprecated and should be written as DocumentXXXResources. I
nevertheless kept the DocumentXXXFonts because our T1fonts are
declared in DSC as "BeginFont ... EndFont" and not as Resources.

> And the "fix" you observe when using dvips is triggered, when
> the font in question is listed at the DocumentNeededFonts and/or the
> DocumentFonts DSC, but not in the DocumentSuppliedFonts. So while
> your proposal seems to resolve the issue (and well, yes, it actually
> does), it does it due to a mis-interpretation of the DocumentFonts
> entries by dvips.

> Actually, to my understanding, DocumentFonts should not be used
> anymore and the stripped font contained in the eps file should not
> be listed in DocumentSuppliedFonts nor in DocumentNeededFonts. I do
> not want to reject all your findings, but to my understanding those
> DSCs are wrong and should not be written into the eps file (of the
> file to be included). It does not at all fix the original source of
> the problem (which is a feature of the CMR-type1 fonts, that they
> are not reloaded from the input stream when it is already available
> in the FontDictionary according to the UniqueID and dvips failing to
> remove the UniqueID when stripping fonts).

So, you propose to keep the old version? I strongly disagree, as these
problems occur far too often. And, we are in away inconsistent in the
use of DSC. We write %%BeginFont/%%EndFont around the font definitions,
but we do not put the corresponding statement in the DSC header.

If your proposition is to circumvent DSC treatment by broken software,
then I would propose to put all the stripped fonts without
%%BeginFont/%%EndFont into the document setup
(%%BeginSetup/%%EndSetup), where postscript code can reside.

So, it comes down to the question: If a software has to combine
several eps files, all coming with their own font, but each of them is
a partial font. Does it have to look into each of them, combining them
to have a full set of necessary glyphs? This would be ideal. But what
can we do to help such a software to recognize the problem?

- At the moment, we use the same name and the same UniqueID for the
  stripped font. We might use XUIDs to inform about the modifications
  we did to the font.

- We might not strip fonts at all (Is there such an option in the
  ps/pdfwriter?)

- Put our non-standard-conforming fonts into the
  %%BeginSetup/%%EndSetup part of the DSC.

Michael

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3240] trunk/pyx/pyx/pswriter.py

[André W. <wo...@us...>]

Hi Jörg,

Am 17.02.2012 um 10:57 schrieb Joerg Lehmann:
>> In the end, I do not see why the registry -- it is not a general
>> registry but a PSregistry -- should not contain PS-specific code like
>> the DSC. We already have similar code in PSdefinition.
> 
> Simply because it is too specific. We could, however,
> add more generic code to allow for adding sections in the first DSC
> section.


While I do see some problems in the Font-DSCs Michael just added, I do support to add DSCs via the registry. The reason is, that DSCs are (to some extend) resource descriptions collected from all the components of the file. There are DSCs (we do not yet support), which are crucial. I remember one (old) use-case where I had to add DSCs, which had been collected from included EPS files (this was related to spot colors). At that point in time we didn't had such a fancy infrastructure like the registry and in the end of the day my solution was to add another "walk-through-all-the-content-to-collect-some-data" like what we're did for the bounding box.

Please consider the font DSCs as a initial and specific solution for a general DSC-handling which surely should be handled via the registry. The details of this functionality has to be developed, but in general (to my current understanding) it is correct to use the registry here.

(Still I think the font-DSCs Michael proposed in this thread are wrong, but this is a different issue.)

Best,


André

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] Missing glyphs when including PyX files

[André W. <wo...@us...>]

Hi Michael,

Am 16.02.2012 um 18:51 schrieb Michael SCHINDLER:
> On 16/02/12, André Wobst wrote:
>> I didn't look into the details you're describing, but I wonder
>> whether it is the same issue discussed in this thread. Please note
>> that I summarized some possible solutions at the end. However,
>> nothing happened after this discussion as is clearly is a dvips bug
>> in the first place.
> 
>> Could you please check whether this is the same issue here? Thanks a
>> lot!
> 
> I checked with the example from Axel (two figures containing only
> text). As I include them in latex, they do not appear at all in my
> ghostview. In the meanwhile, I checked in changeset 3239 which adds a
> DSC to declare all fonts in the document. With this change, everything
> works fine! -- both my minimal example and the one of Axel.

I just checked it myself now. Indeed. What happens here is that due to the DocumentFonts DSC the full CMR10 font (in this example) is included by dvips, not the stripped one. However, the original problem that dvips breaks the included font of the embedded eps file as I described in the old thread. Please see the full thread at http://sourceforge.net/mailarchive/forum.php?thread_name=C877F565-8AC5-4E7B-8D36-D7E32421B3F2%40users.sourceforge.net&forum_name=pyx-user

Your DSC-comments is basically equivalent to the -j0 option for the fonts contained in the included eps file(s).

First of all DSC-comments should be optional in almost all cases. Like this one here. We should not need those comments. They are not required. They can be used for resource management to prevent resources to be included several times in a combined postscript file.

However and first of all, we should *not* write a DocumentSuppliedFonts DSC if we include a stripped version of a font only. Furthermore the DocumentSuppliedFonts is not responsible for the "fix" you observe then using dvips. Instead, it is the DocumentFonts DSC. But this directive is an older and deprecated DSC. It was replaced by DocumentSuppliedFonts and DocumentNeededFonts. The DocumentFonts should contain all fonts listed in both, the DocumentSuppliedFonts and DocumentNeededFonts DSCs. And the "fix" you observe when using dvips is triggered, when the font in question is listed at the DocumentNeededFonts and/or the DocumentFonts DSC, but not in the DocumentSuppliedFonts. So while your proposal seems to resolve the issue (and well, yes, it actually does), it does it due to a mis-interpretation of the DocumentFonts entries by dvips.

Actually, to my understanding, DocumentFonts should not be used anymore and the stripped font contained in the eps file should not be listed in DocumentSuppliedFonts nor in DocumentNeededFonts. I do not want to reject all your findings, but to my understanding those DSCs are wrong and should not be written into the eps file (of the file to be included). It does not at all fix the original source of the problem (which is a feature of the CMR-type1 fonts, that they are not reloaded from the input stream when it is already available in the FontDictionary according to the UniqueID and dvips failing to remove the UniqueID when stripping fonts).

Best,


André

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
  / \ \    / )   wo...@us..., http://www.wobsta.de/
 / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
(_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3240] trunk/pyx/pyx/pswriter.py

[Joerg L. <jo...@us...>]

Hi Michael,

On 17.02.12, Michael SCHINDLER wrote:
> Salut Jörg,
> 
> On 17/02/12, Joerg Lehmann wrote:
> > On 17.02.12, m-s...@us... wrote:
> > > Revision: 3240
> > > +    def writefontnames(self, file):
> > > +        fontnames = [res.t1file.name for res in self.resourceslist if res.type == "t1file"]
> > > +        fontnames += [res.newfontname for res in self.resourceslist if res.type == "reencodefont"]
> > > +        if fontnames:
> > > +            file.write(_DSCsplitline("%%DocumentNeededFonts:", "", fontnames)) # TODO add needed fonts which are not included
> > > +            file.write(_DSCsplitline("%%DocumentSuppliedFonts:", "", fontnames))
> > > +            file.write(_DSCsplitline("%%DocumentFonts:", "", fontnames))
> > > +
> > 
> > ... this looks not like the intended use of the registry. Without
> > looking in the details, the previous solution you checked in looked
> > better. What was the reason for moving this code into the PSregistry?
> 
> First, I wanted to avoid a code duplication. Of course, we could
> introduce writefontnames as a member of _PSwriter, which is closer to
> the DSC writing code. But then, the signature is
> 
> class _PSwriter:
>   def writefontnames(self, file, registry):
> 
> and it does not at all make use of "self" -- so, this is not a better
> place.

We would not need to make this a method of the _PSwriter class. In order
to avoid code duplication you could, e.g., also add a function in the __init__
method.

> In the end, I do not see why the registry -- it is not a general
> registry but a PSregistry -- should not contain PS-specific code like
> the DSC. We already have similar code in PSdefinition.

Simply because it is too specific. We could, however,
add more generic code to allow for adding sections in the first DSC
section.

Cheers,

        Jörg

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3240] trunk/pyx/pyx/pswriter.py

[Michael S. <m-s...@us...>]

Salut Jörg,

On 17/02/12, Joerg Lehmann wrote:
> On 17.02.12, m-s...@us... wrote:
> > Revision: 3240
> > +    def writefontnames(self, file):
> > +        fontnames = [res.t1file.name for res in self.resourceslist if res.type == "t1file"]
> > +        fontnames += [res.newfontname for res in self.resourceslist if res.type == "reencodefont"]
> > +        if fontnames:
> > +            file.write(_DSCsplitline("%%DocumentNeededFonts:", "", fontnames)) # TODO add needed fonts which are not included
> > +            file.write(_DSCsplitline("%%DocumentSuppliedFonts:", "", fontnames))
> > +            file.write(_DSCsplitline("%%DocumentFonts:", "", fontnames))
> > +
> 
> ... this looks not like the intended use of the registry. Without
> looking in the details, the previous solution you checked in looked
> better. What was the reason for moving this code into the PSregistry?

First, I wanted to avoid a code duplication. Of course, we could
introduce writefontnames as a member of _PSwriter, which is closer to
the DSC writing code. But then, the signature is

class _PSwriter:
  def writefontnames(self, file, registry):

and it does not at all make use of "self" -- so, this is not a better
place.

In the end, I do not see why the registry -- it is not a general
registry but a PSregistry -- should not contain PS-specific code like
the DSC. We already have similar code in PSdefinition.

Michael

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3240] trunk/pyx/pyx/pswriter.py

[Joerg L. <jo...@us...>]

Hi Michael,

First: We should definitely add the DSC comments relating to the font
usage. In fact, I don't know why we didn't do this before...

However...

On 17.02.12, m-s...@us... wrote:
> Revision: 3240
>           http://pyx.svn.sourceforge.net/pyx/?rev=3240&view=rev
> Author:   m-schindler
> Date:     2012-02-17 08:52:41 +0000 (Fri, 17 Feb 2012)
> Log Message:
> -----------
> added second postscript font type in PS header
> 
> Modified Paths:
> --------------
>     trunk/pyx/pyx/pswriter.py
> 
> Modified: trunk/pyx/pyx/pswriter.py
> ===================================================================
> --- trunk/pyx/pyx/pswriter.py	2012-02-16 17:41:57 UTC (rev 3239)
> +++ trunk/pyx/pyx/pswriter.py	2012-02-17 08:52:41 UTC (rev 3240)
> @@ -67,6 +67,14 @@
>          for resource in self.resourceslist:
>              resource.output(file, writer, self)
>  
> +    def writefontnames(self, file):
> +        fontnames = [res.t1file.name for res in self.resourceslist if res.type == "t1file"]
> +        fontnames += [res.newfontname for res in self.resourceslist if res.type == "reencodefont"]
> +        if fontnames:
> +            file.write(_DSCsplitline("%%DocumentNeededFonts:", "", fontnames)) # TODO add needed fonts which are not included
> +            file.write(_DSCsplitline("%%DocumentSuppliedFonts:", "", fontnames))
> +            file.write(_DSCsplitline("%%DocumentFonts:", "", fontnames))
> +

... this looks not like the intended use of the registry. Without
looking in the details, the previous solution you checked in looked
better. What was the reason for moving this code into the PSregistry?

>  #
>  # Abstract base class
>  #
> @@ -159,12 +167,8 @@
>          if pagebbox:
>              file.write("%%%%BoundingBox: %d %d %d %d\n" % pagebbox.lowrestuple_pt())
>              file.write("%%%%HiResBoundingBox: %g %g %g %g\n" % pagebbox.highrestuple_pt())
> -        fontnames = [res.t1file.name for res in registry.resourceslist if res.type == "t1file"]
> -        if fontnames:
> -            file.write(_DSCsplitline("%%DocumentNeededFonts:", "", fontnames)) # TODO add needed fonts which are not included
> -            file.write(_DSCsplitline("%%DocumentSuppliedFonts:", "", fontnames))
> -            file.write(_DSCsplitline("%%DocumentFonts:", "", fontnames))
>          self.writeinfo(file)
> +        registry.writefontnames(file)
>          file.write("%%EndComments\n")
>  
>          file.write("%%BeginProlog\n")
> @@ -224,12 +228,8 @@
>          if documentbbox and writebbox:
>              file.write("%%%%BoundingBox: %d %d %d %d\n" % documentbbox.lowrestuple_pt())
>              file.write("%%%%HiResBoundingBox: %g %g %g %g\n" % documentbbox.highrestuple_pt())
> -        fontnames = [res.t1file.name for res in registry.resourceslist if res.type == "t1file"]
> -        if fontnames:
> -            file.write(_DSCsplitline("%%DocumentNeededFonts:", "", fontnames)) # TODO add needed fonts which are not included
> -            file.write(_DSCsplitline("%%DocumentSuppliedFonts:", "", fontnames))
> -            file.write(_DSCsplitline("%%DocumentFonts:", "", fontnames))
>          self.writeinfo(file)
> +        registry.writefontnames(file)
>  
>          # required paper formats
>          paperformats = {}

Cheers,

        Jörg

Re: [PyX-devel] Missing glyphs when including PyX files

[Michael S. <m-s...@us...>]

Salut André,

On 16/02/12, André Wobst wrote:
> I didn't look into the details you're describing, but I wonder
> whether it is the same issue discussed in this thread. Please note
> that I summarized some possible solutions at the end. However,
> nothing happened after this discussion as is clearly is a dvips bug
> in the first place.

> Could you please check whether this is the same issue here? Thanks a
> lot!

I checked with the example from Axel (two figures containing only
text). As I include them in latex, they do not appear at all in my
ghostview. In the meanwhile, I checked in changeset 3239 which adds a
DSC to declare all fonts in the document. With this change, everything
works fine! -- both my minimal example and the one of Axel.

So, I conclude that we were really missing a DSC and this was also a
bug in PyX. I checked the reference for that (5001.DSC_Spec.pdf) and I
have the impression that it is indeed requires. I added all three
comments as %%DocumentFonts cures the problems but is considered to be
superseded by %%DocumentSuppliedFonts, which does not cure them.


Michael

Re: [PyX-devel] Missing glyphs when including PyX files

[André W. <wo...@us...>]

Hi Michael,

I didn't look into the details you're describing, but I wonder whether it is the same issue discussed in this thread. Please note that I summarized some possible solutions at the end. However, nothing happened after this discussion as is clearly is a dvips bug in the first place.

Could you please check whether this is the same issue here? Thanks a lot!

Best,


André Wobst


Am 16.02.2012 um 17:14 schrieb Michael SCHINDLER:

> Rehello,
> 
> I have another piece of information concerning the glyph problem:
> 
> I tried to reproduce the same problem only using latex+dvips:
> 
> inset.tex:
> \documentclass{article}
> \pagestyle{empty}
> \begin{document}
> Hello, world!
> \end{document}
> 
> test.tex:
> \documentclass{article}
> \usepackage{graphicx}
> \begin{document}
> Word.
> \includegraphics{inset}
> Another word.
> \end{document}
> 
> then run with
> 
> latex inset ; dvips -E -o inset.eps inset
> latex test ; dvips test
> 
> The produced file inset.eps contains the same "{restore} if". It
> contains also in the beginning comments a line
> 
> %%DocumentFonts: CMR10
> 
> If I delete this line, then I have the same behaviour as with the
> PyX-EPS. Deleting also the "{restore} if" cures it again. So, if the
> "{restore} if" is really at its proper place, we should consider
> listing the used fonts in the preamble comment.
> 
> 
> Michael
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> PyX-devel mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] Missing glyphs when including PyX files

[Michael S. <m-s...@us...>]

Rehello,

I have another piece of information concerning the glyph problem:

I tried to reproduce the same problem only using latex+dvips:

inset.tex:
\documentclass{article}
\pagestyle{empty}
\begin{document}
Hello, world!
\end{document}

test.tex:
\documentclass{article}
\usepackage{graphicx}
\begin{document}
Word.
\includegraphics{inset}
Another word.
\end{document}

then run with

latex inset ; dvips -E -o inset.eps inset
latex test ; dvips test

The produced file inset.eps contains the same "{restore} if". It
contains also in the beginning comments a line

%%DocumentFonts: CMR10

If I delete this line, then I have the same behaviour as with the
PyX-EPS. Deleting also the "{restore} if" cures it again. So, if the
"{restore} if" is really at its proper place, we should consider
listing the used fonts in the preamble comment.


Michael

[PyX-devel] Missing glyphs when including PyX files

[Michael S. <m-s...@us...>]

Hello,

I would like to come back to the old story about some glyphs missing
when PyX figures are included in other (postscript) documents.

* We had the discussion about including PyX-EPS files in latex and
  then processing it with dvips.
  The final statement was (in short) that it is not a bug in PyX but
  in dvips, related to the treatment of UniqueID.
  http://permalink.gmane.org/gmane.comp.python.pyx.users/1228

  Also interesting:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575469

* Now, I came across the same symptom in a different context: The
  journal "Soft Matter" (they certainly do not use TeX, the math
  typesetting is too ugly). In one of the figures I sent them there
  are also glyphs missing (1,l,n,i,r,v) -- I do not know whether they
  took the EPS or the PDF file.

After some digging with the minimal example I could hunt the problem
down to a line in the font definition in the PyX-EPS file:

fig.py:
from pyx import *
c = canvas.canvas()
c.text(0, 0, "Hello, world!")
c.writeEPSfile("fig.eps")

test.tex:
\documentclass{article}
\usepackage{graphicx}
\begin{document}
Word.
\includegraphics{fig.eps}
Another word.
\end{document}

Run
   python fig.py; latex test; dvips test

My file fig.eps produces the described effect,
   "Hello world!" reads in test.ps:
   " e  o wor d ".

In fact, my file fig.eps contains the following lines 355-361:

0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
cleartomark
{restore}if

%%EndFont
%%EndProlog


If I delete the "{restore} if" line, then everything works fine! I do
not see what is to be restored at the point of font definition anyway
(but this is postscript, not easy to read).

It is also interesting to compare the EPS file with one that has been converted
from PyX-PDF file, using the "pdftops" tool (from kpdf)

  pdftops -eps fig.pdf fig_kpdf.eps

There are some differences in the "%%" directives, using "%%BeginResource"
instead of our "%%BeginFont", but one of the differences is also that there is
no "{restore} if". If I add this line after the "cleartomark" in the
kpdf-generated EPS file, I observe that the *very same* glyphs are
missing in test.ps.

To conclude, I do think that this is a PyX bug. We should strip the
"{restore} if" when including a font.


Michael

Re: [PyX-devel] [PATCH] fix plot style breakage

[André W. <wo...@us...>]

Dear Michael,

good catch, thanks, checked in as changeset 3238.

(This recent code move is part of some major graph (axis) reorganization. But I'm not working on it at the moment. It has to wait for another two months or so.)

Best,


André


Am 22.12.2011 um 14:26 schrieb Michael J Gruber:

> r3235 moved plot styles to graph.style. As a result, plotitem raises
> 
> AttributeError: 'module' object has no attribute 'getdefaultprovider'
> 
> because style.getdefaultprovider() does not find getdefaultprovider when
> called in the module style (graph.style).
> 
> Fix this by referencing getdefaultprovider() directly (without the
> module) in that module.
> 
> Signed-off-by: Michael J Gruber <mic...@us...>
> ---
> pyx/graph/style.py |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/pyx/graph/style.py b/pyx/graph/style.py
> index 4afc047..9471b2f 100644
> --- a/pyx/graph/style.py
> +++ b/pyx/graph/style.py
> @@ -56,7 +56,7 @@ class plotitem:
>             for s in styles:
>                 for n in s.needsdata:
>                     if n not in provided:
> -                        defaultprovider = style.getdefaultprovider(n)
> +                        defaultprovider = getdefaultprovider(n)
>                         addstyles.append(defaultprovider)
>                         provided.extend(defaultprovider.providesdata)
>                 provided.extend(s.providesdata)
> -- 
> 1.7.8.1.461.g7edd2
> 
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> PyX-devel mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/