Intaglio
23 replies to this thread. Most Recent
Here is another one
Download the following file:
http://privatewww.essex.ac.uk/~mjr/Cranky_UG_test.intaglio.zip
Look inside the blue circle, on the left, at Temple station.
That’s not right, the District Line (green) should be touching the Circle Line (yellow), and I’m sure that arc was OK when I first spliced it in.
Use the Point Selection Tool (white arrow) to take a look at the control handles on the points of arc. The handle right next to Temple Station on the District Line (green) should be horizontal. It’s not, and that is forcing down the District line, so shift-control the handle to get it back to horizontal, then select that point and nudge up a few pixels to get the line back to parallel and touching the Circle Line.
Now save and reopen. Ho hum, back to how it was before.
The way I fixed this was to cut out the arc segment and splice a new one in. So, for some reason, that particular part of the curve had got corrupted.
IMPORTANT: the problems can be fixed, but it takes/wastes time, and I can only fix problems that I see. This one was spotted because the non-parallel lines made it obvious, but are there other lurking problems that I have not spotted yet because they are less obvious.
Max Hi, On 22 Oct 2008, at 11:48, Max Roberts wrote:
Download the following file:
http://privatewww.essex.ac.uk/~mjr/Cranky_UG_test.intaglio.zip
Look inside the blue circle, on the left, at Temple station.
That’s not right, the District Line (green) should be touching the Circle Line (yellow), and I’m sure that arc was OK when I first spliced it in.
Use the Point Selection Tool (white arrow) to take a look at the control handles on the points of arc. The handle right next to Temple Station on the District Line (green) should be horizontal. It’s not, and that is forcing down the District line, so shift- control the handle to get it back to horizontal, then select that point and nudge up a few pixels to get the line back to parallel and touching the Circle Line.
Now save and reopen. Ho hum, back to how it was before. Repeated your procedure. Handle was horizontal already but the line was not aligned. I selected the point. Shifted it up by one pixel, saved and closed. When I reopened things were as before. Your problem has been reproduced. Intaglio 3.0.1, Mac Pro, OSX 10.5.5 Leopard Best wishes Julius
Le 22 oct. 08 à 12:48, Max Roberts a écrit :
( ) Now save and reopen.
All that I have done
Ho hum, back to how it was before.
No ! Everything is OK, how I have modified it !
¿¿¿¿¿¿¿¿¿?????????
jacques
jacques
iMacG5 20” — iBookG4 14” — MacOS X 10.4.9 — RagTime 6.0.2 (1632) — Intaglio 2.9.6 — ChemDraw 9.0.1
Your problem has been reproduced. Intaglio 3.0.1, Mac Pro, OSX 10.5.5 Leopard
I cannot reproduce the problem ! Intaglio 3.0.1, IMacG5 10.4.11 Tiger, Logitech mouse with grey cord
jacques
jacques
iMacG5 20” — iBookG4 14” — MacOS X 10.4.9 — RagTime 6.0.2 (1632) — Intaglio 2.9.6 — ChemDraw 9.0.1
On 22 Oct 2008, at 20:48, Jacques Villars wrote:
Your problem has been reproduced. Intaglio 3.0.1, Mac Pro, OSX 10.5.5 Leopard
I cannot reproduce the problem ! Intaglio 3.0.1, IMacG5 10.4.11 Tiger, Logitech mouse with grey cord
jacques Perhaps a quick list of who can and who cannot? so far then Max has the problem with 10.4.9 to 10.4.11. Both computers are Intel Mac Mini, 2GB Julius has same with Mac Pro, OSX 10.5.5 Leopard
Jacques No Problem with IMacG5 10.4.11 Tiger and the gray tailed Logitech mouse Ian No Problem but don’t know the machine
Julius >
Julius—I have a similar setup to yours; G5 iMac 1.5gb ram, OS 10.4.11.
I opened the map in the v3.01 demo, which can’t save in the Intaglio format, but can save EPS and PDF files. When the EPS and PDF versions were opened in v2.9.8, the lines could be modified, locked, saved and re-opened without any problems.
There was a shift, but it wasn’t in the drawing. When the EPS was opened in Intaglio, some of the station names had moved. Blocks of names were in the same text box, aligned left and spaced vertically with leading. Moorgate, Bank and Monument were in one text box, with Temple and Embankment in another.
Did Intaglio do this during the conversion to EPS?
Believe it or not, when the same EPS was opened in Preview, all the station names appeared in the correct positions…
Ian Hi, On 23 Oct 2008, at 00:59, IanB wrote:
Julius=97I have a similar setup to yours; G5 iMac 1.5gb ram, OS = 10.4.11.
I opened the map in the v3.01 demo, which can=92t save in the Intaglio = =20 format, but can save EPS and PDF files. When the EPS and PDF =20 versions were opened in v2.9.8, the lines could be modified, locked, =20=
saved and re-opened without any problems. Intaglio was able to recover all the structural information from the =20 EPS and PDF files? Wow! See below.
There was a shift, but it wasn=92t in the drawing. When the EPS was =20=
opened in Intaglio, some of the station names had moved. Blocks of =20 names were in the same text box, aligned left and spaced vertically =20=
with leading. Moorgate, Bank and Monument were in one text box, with =20=
Temple and Embankment in another. I don’t know how they were designed to be but all the stations you =20 mention came through to me as separate entities, i.e. in their own =20 boxes. I have just saved as eps and read it back in. The whole thing looks like one graphic. This does not surprise me since eps produces a postscript file which =20 is just a set of directives to be executed by a printer. http://en.wikipedia.org/wiki/Encapsulated_PostScript and http://en.wikipedia.org/wiki/PostScript Ditto the pdf converts into its own format http://en.wikipedia.org/wiki/Portable_Document_Format
Upshot of all this is that most Intaglio formatting information should =20=
have been lost. That Intaglio is able to recover (earlier in your text) looks to me =20 like it must be clever stuff but then I don’t have direct experience =20 of working with postscript so all my assumptions must be wrong. I note that EPS is designed so it can be embedded in postscript files =20=
so perhaps it is also able to save the structural information…. This =20=
line of thought of mine makes no sense to me. But wait, it appears =20 that eps formed basis for adobe illustrator artwork so the structural =20=
info might well be there. So it goes. > >
Did Intaglio do this during the conversion to EPS?
Believe it or not, when the same EPS was opened in Preview, all the =20=
station names appeared in the correct positions=85
Yes but the Preview was reading it as an EPS file and I guess that =20 Intaglio was reading it as something to be converted into Intaglio =20 format?
It is very difficult for me even to guess at what might be happening =20 to cause the errors described by Max. This is especially so since I am =20=
a recent user of Intaglio and I only use it to produce rough diagrams =20=
to document the graphic operations I am implementing computationally. =20=
The most complex thing I do with it is group and ungroup! I also work =20=
at A4 size which I doubt puts any stress on memory usage.
It could be something as simple as a difference in resolution in the =20 arithmetic. It is possible that for some reason Intaglio performs a =20 variety of floating point to integer to floating point etc convertions =20=
and the cumulative rounding errors produce the difference. On my =20 machine it was a very small one pixel error. The file I received was zoomed to 400% and possibly the zoom =20 operations had an effect. The thing is that without knowing anything about the logical structure =20=
of intaglio it is impossible to say other than that the error has =20 shown itself to exist (or at least one part of the error has - since I =20=
have not explored further) on three different machines and two =20 different operating systems.
I guess the thing to do is to make a bug report containing all the =20 information gathered so far.
All the best Julius
I don’t get the problem either by saving to pdf, so it is something about writing to an Intaglio file that is not being done properly. A cache not being updated properly or something like that? So that although the change is registered in memory, for whatever reason it never makes it to an Intaglio file.
Of course, it would be nice if the objects did not get corrupted to begin with, but not being able to correct them is frustrating.
Just for the record, here is a screen dump of what the second test file should look like when open (I changed colours so that the cpntrol handles would be more visible.
privatewww.essex.ac.uk/~mjr/mjr.png
Max hi On 23 Oct 2008, at 09:45, Max Roberts wrote:
I don’t get the problem either by saving to pdf, so it is something about writing to an Intaglio file that is not being done properly. A cache not being updated properly or something like that? So that although the change is registered in memory, for whatever reason it never makes it to an Intaglio file.
Of course, it would be nice if the objects did not get corrupted to begin with, but not being able to correct them is frustrating.
Just for the record, here is a screen dump of what the second test file should look like when open (I changed colours so that the cpntrol handles would be more visible.
privatewww.essex.ac.uk/~mjr/mjr.png
I include two png images of what the file you sent me looked like. Notice the first differs in the colour of the control points plus the existence in yours of a blue and white control point in the rectangular station indicator beneath the m in Temple. The second reproduces (but smaller) what you sent exactly but only by my holding down the ctrl key as I clicked on the places where the points were/should be.
Who would one file a bug report with if one were to do so? Presumably Intaglio people keep an eye on the message boards so I’m at a bit of a loss to understand why they have not yet joined in the discussion. Ditto regarding a little complaint I aired on these boards a couple of weeks ago about my inability to copy and paste file names into the save file box which to no reply received I. So it goes. Perhaps they’re all busy preparing 3.0.2 which will resolve all our issues.
all the best Julius
PS. I had to send again with much reduced images because the mailing list complained about me sending a 100K or so of data. Lets hope this one fares better.
Hello Max, here the file that I have modified, with a screencopy of the result ; what happens on opening on your system ? does it remain how I have closed it (cf. screen copy) or with a new bug ? jacques
Le 23 oct. 08 à 10:45, Max Roberts a écrit : > >
Just for the record, here is a screen dump of what the second test file should look like when open (I changed colours so that the cpntrol handles would be more visible.
privatewww.essex.ac.uk/~mjr/mjr.png
jacques
iMacG5 20” — iBookG4 14” — MacOS X 10.4.9 — RagTime 6.0.2 (1632) — Intaglio 2.9.6 — ChemDraw 9.0.1
That’s intriguing stuff, Julius, but your comments pose yet more questions!
As I’m not a programmer, the Wikipedia pages are tough going. ‘PDF…is a sub-set of the Postscript page description language…’; ‘The graphics commands that are output by the PostScript code are collected and tokenized;…’ It’s all very mysterious.
A possible solution to the moving text/graphics problem:
Save as an EPS, open in Preview and select Copy.
Create a new Intaglio document and select Paste. To edit the map, select Ungroup and delete the grey box that covers the map.
When I used this procedure on the map, the graphics and station names didn’t move about.
Opening PS and EPS files directly in Intaglio isn’t easy. Some open but more often than not, you get an error message and hardly any Adobe Illustrator files open in either Intaglio or Preview. It would be helpful if this could be solved. Incidentally, what’s the difference between the AI, PS and PDF formats? Does anyone know any tricks which might persuade stubborn files to open?
By the way, Copy and Paste to the Save dialogue box works here, both from Intaglio and the Finder.
Ian,
Trouble converting to EPS and back to Intaglio is that I lose all the layers. Now, if Intaglio had a proper layer inspector (cf Canvas) it would be possible to select groups of objects via this window and relayer them quickly. This is because the PDF will still have all the objects stacked in the same order as the original, which means that similar-layered objects would be adjacent in the layer inspector window, if it could display objects that is.
Here is a quick tip. If the colours matter, in other words you have defined exact CMYK colours for your objects, never export as PDF, the colours will look similar but in fact their precise make-up will have been changed. Important if you are trying to match colour specifications (e.g. getting an Underground line in the corporate colour), very important if you want something printed in true black, 100%K, because the conversion process will take away some K and add in some CMY to it! That makes a complete mess of overprinting, black should always be set to overprint for anything going to repro, but only pure black can easily be flagged to overprint.
If you export as EPS, and then convert to PDF either by Acrobat or Preview, the colours don’t get changed at all, they all come out perfectly.
Jacques,
Thanks very much. Whatever you did has fixed the file and that object is no longer corrupted.
Can I just confirm, when you opened my original file, it was wrong, but when you fixed it, it stayed fixed.
Ian,
You suggested some workarounds (e.g. align objects on my other post rather than move the line to the circles) but, for example, if you did move the line to the circles, did you get the return-after-save problem that I have?
The feeling I am getting from the posts is that this might be a problem for Intel Macs? Nice to have a comment from the gods on this one. I can reproduce the bug to order on my computer, but my house is rather a long way for Nick to travel!
Ian hi, I’ll deal with the last bit first On 24 Oct 2008, at 01:16, IanB wrote: >
By the way, Copy and Paste to the Save dialogue box works here, both =20=
from Intaglio and the Finder. O.K. Thanks. It’s good to know the thing is local. On Paste I get an alert box which says
Can’t complete this command -25130
On copy I get no response and nothing goes into the clipboard. Ditto on cut.
This is rather strange since I would suspect that Intaglio 3.0.1 is =20 programmed using Cocoa, XCode and Interface Builder and therefore will =20=
call up the standard Save panel NSSavePanel which I believe to be the =20=
component used in all cocoa based saves all of which appear to provide =20=
a copy and paste facility as default. For instance if I run XCode and create a new document based =20 application this creates all the save etc facilities for me as =20 default. If I now, without doing anything further, run this skeleton =20 program, I am able to bring up the save panel and copy and paste into =20=
it just like that. It is possible though I don’t know enough about it that 3.0.1 is =20 written in Carbon and I believe OS 10.5 leopard has or is withdrawing =20=
support for Carbon because of it representing the start of apple’s =20 move with Intel to 64 bit computing (the length of each machine code =20 instruction which previously was either 16 bit or 32 and even 48 bit)
My references to these Mac programming software and tools are =20 technical but save me writing lots of words. http://developer.apple.com/referencelibrary/Cocoa/index.html http://developer.apple.com/referencelibrary/Carbon/index.html http://developer.apple.com/referencelibrary/DeveloperTools/index.html
But as I know to my cost, it having taken me about a year’s hard slog =20=
to get up to modest speed with Cocoa programming e.g. http://www.cocoabuilder.com/archive/message/cocoa/2008/5/18/207047 and = http://juliuspaintings.co.uk/cgi-bin/paint_css/animatedPaint/animatedPaint= .pl
Cocoa is hard to get to know and so full of pitfalls that the cocoa =20 mailing list goes out about 4 or 5 times a day with about ten or more =20=
messages each time. But all of the above is just guesswork.
That=92s intriguing stuff, Julius, but your comments pose yet more =20 questions!
As I=92m not a programmer, the Wikipedia pages are tough going. =91PDF=85= =20 is a sub-set of the Postscript page description language=85=92; =91The = =20 graphics commands that are output by the PostScript code are =20 collected and tokenized;=85=92 It=92s all very mysterious.
Ok. sorry to point you at technical speak and using it myself in my =20 previous comments. I’ll try to clarify as briefly as I can.
When a program sends a page to the printer for printing it first =20 encodes it into a set of numbers which instruct the printer as to =20 where to print black, or a colour and where not. That encoding is =20 performed using a set of machine interpretable conventions that are =20 referred to as a language, in this case a “page description language”. =20=
Some of these conventions aka languages are Postscript, EDS and PDF.
One feature of computer languages is that in the decoding process, =20 statements in those languages tend to be translated into statements in =20=
other, simpler languages. More or less like when as I am doing now, I =20=
try to translate the computereese of the wiki page into something more =20=
human readable for this list. During this translation process the =20 various grammatical units of the statements become replaced by other =20 units sometimes refered to as tokes.
Now hopefully to convert the wiki sentence into english:
<quote>
Often, the PostScript-like PDF code is generated from a source =20
PostScript file. The graphics commands that are output by the =20
PostScript code are collected and tokenized; any files, graphics, or =20
fonts to which the document refers also are collected; then, =20
everything is compressed to a single file. Therefore, the entire =20
PostScript world (fonts, layout, measurements) remains intact.
PostScript-like PDF code =3D the statements written in the PDF language generated from a source PostScript file =3D the input file written in =20=
Postscript The graphics commands =3D the computer instructions used to generate a =20=
picture (on screen) or instruct a printer are collected and tokenized =3D are translated into the common set of =20=
conventions being used but without loss of information, ie. one can in =20=
this instance translate both ways, reproducing the original in each =20 case. everything is compressed to a single file =3D compressed is just that, =20=
e.g. jpeg is a compressed graphic, .zip is a compressed text or binary =20=
file. Therefore, the entire PostScript world (fonts, layout, measurements) =20 remains intact. =3D the file still contains all the information =20 contained in the original Postscript file.
In summary: A PDF file is an amalgam of data obtained from various =20 sources including a Postcript file whose contents are included without =20=
loss of information, i.e. we can generate the original Postscript file =20=
from the PDF file.
Sorry. Can’t go on. This will have to do. Just hope it could be =20 understood. In future I’ll try to use standard English in my comments.
Best wishes Julius
Le 24 oct. 08 à 09:34, Max Roberts a écrit :
Whatever you did has fixed the file and that object is no longer corrupted.
Can I just confirm, when you opened my original file, it was wrong, but when you fixed it, it stayed fixed.
OK. But can you now properly change anything in the file I have e- mailed to you ? or do you get a new bug ?
jacques
jacques
iMacG5 20” — iBookG4 14” — MacOS X 10.4.9 — RagTime 6.0.2 (1632) — Intaglio 2.9.6 — ChemDraw 9.0.1
Max,
Re: the loss of layers in PDFs, according to the Acrobat Reader Info panel, Intaglio PDFs are PDF Version 1.3 (Acrobat 4). An Adobe TechNote says; ‘Note: In PDF 1.3 files, layers and preview transparency aren’t preserved.’
A page on Adobe’s web site ‘About PDF Layers’, says: ‘To retain layers when you convert InDesign CS or later documents to PDF, make sure that Compatibility is set to Acrobat 6 (PDF 1.5) and that Create Acrobat Layers is selected in the Export PDF dialog box.’
To preserve layers, you’ll probably have to stick with the Intaglio format.
Re: Shifting/Alignment, apart from the moving text problem, I’ve had no problems with objects shifting after saving. I mix and match alignment methods. Sometimes I use the palette, sometimes the red guides.
Re: Colour, colour repro is a minefield. If you’re using outside repro and printing houses, it’s best to ask them what they need to do the job. Sophisticated design effects are pointless if the output equipment can’t reproduce them. The best way is to keep it simple.
Thanks for the tip about converting from EPS to PDF in Preview.
I must say that as well as being a very good drawing program, Intaglio is the most useful app for opening files.
Le 22 oct. 08 à 23:25, julius a écrit :
Perhaps a quick list of who can and who cannot?
( )
Jacques No Problem with IMacG5 10.4.11 Tiger and the gray tailed Logitech mouse
I have just tried : also no problem on iBookG4, 10.4.11 (the mousetail is here light grey and there is no coffee cup on the desk)
jacques
jacques
iMacG5 20” — iBookG4 14” — MacOS X 10.4.9 — RagTime 6.0.2 (1632) — Intaglio 2.9.6 — ChemDraw 9.0.1
Le 25 oct. 08 à 13:48, Jacques Villars a écrit :
> I have just tried : also no problem on iBookG4, 10.4.11 (the mousetail is here light grey and there is no coffee cup on the desk)
And now my daughter has just tested the original file on MacBook Intel Core Duo, Leopard 10.5.5 : the bug is there !
jacques
jacques
iMacG5 20” — iBookG4 14” — MacOS X 10.4.9 — RagTime 6.0.2 (1632) — Intaglio 2.9.6 — ChemDraw 9.0.1
Intel Macs, my hunch was correct. Thanks for everyone who helped track this down. Nick, over to you.
Max
Thanks to everyone for looking into this. The problem is due to a very obscure byte swapping problem when running on Intel. For example, swapping the number 910.9999 then swapping it back produces 911.9999 (i.e., off by one). Apparently Intaglio’s method of swapping floating point numbers is incorrect in very rare circumstances. I’ll figure it out and post a fix.
Nick Hi, On 29 Oct 2008, at 18:31, Nick wrote:
Thanks to everyone for looking into this. The problem is due to a very obscure byte swapping problem when running on Intel. For example, swapping the number 910.9999 then swapping it back produces 911.9999 (i.e., off by one). Apparently Intaglio’s method of swapping floating point numbers is incorrect in very rare circumstances. I’ll figure it out and post a fix.
When I first saw this email I had no idea of why one would want to swap bytes, and especially why one might want to do this with floating point numbers. So I googled “swapping floating point numbers”
and think I now understand.
Then I remembered that I had been quite technical in one of my previous postings so I thought I’d share my understanding.
It’s been years since I’ve had even a tiny look at machine level numeric representations so I needed to check that floating point numbers are still held in mantissa/exponent format. e.g. 100.605 = 0.100605 x 1000 and 1000 is 10 cubed, that is 10**3. In this case 0.100605 is the mantissa and 3 the exponent
e.g. see this floating point number tutorial http://www.cs.utah.edu/~zachary/isp/applets/FP/FP.html
this IEEE standard http://steve.hollasch.net/cgindex/coding/ieeefloat.html
And the para headed “inexactness” three paragraphs down this page is also interesting but I don’t think pertinent to the present case. http://www.lahey.com/float.htm
The top of the google results for “swapping floating point numbers” http://davyd.livejournal.com/261616.html
said this interesting thing
<quote>
Say you’ve got a buffer full of big-endian floats. They might have
come from a file or the network. You’d really like them in your system
endian so that you can do something with them.
What this quote reveals is the existence of a problem when moving numbers between computers.
“endian” refers to ways of storing numbers in a computer. http://en.wikipedia.org/wiki/Endianness http://www.webopedia.com/TERM/B/big_endian.html
If data is being moved between computers, e.g. from a mac to a pc or vice versa it is possible that there will be a need to translate the numbers from big-endian to little-endian or vice-versa.
However according to the mac cocoa documentation the problem can also occur when moving numbers about the same machine and especially now that apple is moving from a 32 bit to 64 bit representation on its Intel machines.
http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Tasks/ByteSwapping.html#/ /apple_ref/doc/uid/20001155-101132-TPXREF111
<quote> Byte Swapping Floating-Point Values
Even on a single platform there can be many different representations
for floating-point values. Unless you are very careful, attempting to
pass floating-point values across platform boundaries causes no end of
headaches. To help you work with floating-point numbers, Core
Foundation defines a set of functions and two special data types in
addition to the integer-swapping functions. These functions allow you
to encode 32-and 64-bit floating-point values in such a way that they
can later be decoded and byte swapped if necessary.
Hope this was of interest
Nick, good luck figuring out the solution
all the best
Julius
I’ve posted a test version of 3.0.2a2 with a fix for this Intel file reading problem. It can be downloaded at:
Nick Bravo. Tested it on Cranky_UG_test and worked perfectly. Mac pro os 10.5.5. all the best Julius On 31 Oct 2008, at 20:03, Nick wrote:
I’ve posted a test version of 3.0.2a2 with a fix for this Intel file reading problem. It can be downloaded at:
Nick,
All my test files worked perfectly, thanks very much for sorting this out quickly.
I can sleep more peacefully at night knowing that I won’t have to switch to Illustrator!
Max
