[duxhelp] Re: Problem with 4X4 pro (continued)
- From: "Peter Sullivan" <peter@xxxxxxxxxx>
- To: <duxhelp@xxxxxxxxxxxxx>
- Date: Fri, 23 Feb 2007 00:24:25 -0400
Dear Yves,
This beta cycle isn't working out well for you; I'm sorry about that.
We haven't had any breakthrough on the issue with non-folio formats on the
4x4. Few people on the list are able to provide us with help right away.
It appears that we'll have to put this issue off until after the release of
SR1. We are quite certain that we'll be able to fix the issue, and that
we'll be able to make available a two file "patch" as soon as we know how to
correct the problem. That shouldn't be long, but given that we're unable
even to predict a date definite right now, we can no longer hold up the
release, which contains many other needed improvements.
With regard to how form sizes correspond to cell and line counts, we cannot
really separate this issue from more fundamental problems with non-folio
output from DBT on a 4x4, so this correction will be included in the "patch"
that should be forthcoming, but not in SR1 itself.
Finally, on the matter of the error message, I agree that DBT is not
behaving well in this regard, but here again we aren't able to fix this for
SR1. The reasons are two-fold. One reason is that DBT is localized to
operate in about ten different languages. We rely on third-parties, who
have different schedules, to create the localized messages. So any change
that we make to the language of the user interface will not be available in
all languages for a week or more. To keep things consistent without
frequently introducing delays in the process, we press very hard to avoid
user interface changes after the first round of beta testing. In this
particular case, there is another reason we are unable to fix this issue.
To distinguish the case where a document will be reformatted from a case
where it won't will sometimes require more information than DBT has recorded
in the document files. This is due to an omission of information in the DBT
document format; DBT doesn't record the type of embosser for which an
document is formatted, but only the configuration name. I should have
forseen the need for the additional data, but did not. This complicates the
handling of this situation quite a bit. The only entirely satisfactory
solution will be to extend DBT's file format a bit again. But this is
something that we generally won't consider doing late in a beta cycle unless
a defect is something that will cause enormous problems. In this case, we
believe that the problems are likely to be overcome with a short
explanation, and we don't want to set release back by several weeks to avoid
this.
I hope that your vacation has been relaxing. I'll be back in touch with
regard to the problems we are having driving the 4x4 and also with regard to
the screen updating speed.
Best Regards,
Peter
-----Original Message-----
From: duxhelp-bounce@xxxxxxxxxxxxx [mailto:duxhelp-bounce@xxxxxxxxxxxxx] On
Behalf Of Yves DUNAND
Sent: Monday, February 19, 2007 12:43 PM
To: duxhelp@xxxxxxxxxxxxx
Subject: [duxhelp] Re: Problem with 4X4 pro (continued)
Hi David and all,
Unfortunately, I haven't got access to a 4X4 PRO embosser today and will be
leaving for a week's vacation this evening, so I hope others will be able to
respond to your request for testing with non-folio formats. If I may make a
suggestion, it would be, for the format named "A4, 21 X 29,7 cm", to revert
to the parameters we had in 10.5, that is :
either Form "12_n" = 85 x 120 ; SinglePage ; 34 x 30 ; 32 x 28
or Form "12_w" = 115 x 120 ; SinglePage ; 42 x 30 ; 40 x 28
Of course I am by no means a technician, but what I can say is that
embossing with 4X4 was working fine with those parameters in 10.5 whereas
the new ones in 10.6 are far below what is expected with paper that size.
On the other hand, I'd like to insist on the second point I made
concerning the error message we get when the name of the targetted embosser
is not exactly the same as the one written in the template. Ideally, DBT
should be able to detect that the document's parameters are the same as the
embossers', in spite of the different name. If it can't do that, at least
the user should not be mislead into thinking that there is definitely
something wrong with his or her document, but rather prompted to check those
parameters if in doubt.
Best regards
Yves
----- Message d'origine -----
De : David Holladay <mailto:david@xxxxxxxxxx>
À : duxhelp@xxxxxxxxxxxxx
Envoyé : vendredi 16 février 2007 15:53
Objet : [duxhelp] Re: Problem with 4X4 pro (continued)
Yes, there have been issues with the Index 4x4.
I made many assumptions about the Index 4x4 in the past. I visited
Sighted Electronics in NJ (USA) September 2005 to learn more about it. Based
on that visit, I made radical changes to how the Index 4x4 has been
supported in DBT. These changes abandoned non-folio output and focused on
folio output only.
When we tried to support non-folio output, we had problems. I have
some e-mails into Index in Sweden and hope to better support the Index 4x4
for all of its modes.
If you can tell me if you have had success with DBT and non-folio
output, that might help me quite a bit.
-- David Holladay
At 06:43 AM 2/16/2007, you wrote:
Hello all,
I went through a series of e-mails concerning problems with
4X4 pro embossers and I understand that David Holaday is about to make some
changes in the emb.elt file to fix them. Hoping this will help, heres my
feedback on what we have observed since installing 10.6.
Whilst we had no problem embossing with 10.5 using 12_n for
A4 paper, with 30 characters per line AND 27 lines per page, we have
observed that the corresponding 12_n form no longer exists in the new
emb.elt file. Instead, we have to use
Form "A4_folio", where the parameters don't appear to be
correct. They read
Form "A4_folio" = 83 x 117; DoublePage ; 22 x 20 ; 20 x 20
instead of what we had with 10.5 which was
Form "12_n" = 85 x 120 ; SinglePage ; 34 x 30 ; 32 x 28
or
Form "12_w" = 115 x 120 ; SinglePage ; 42 x 30 ; 40 x 28
Could the 12_n (and maybe the 12_w also) form be restored
with the right parameters in order to ensure compatibility with 10.5 ? Or
could the parameters for "A4_folio" be corrected to get back to what we had
with the equivalent paper size ?
Besides, I don't know if there is any connexion between the
two problems, but with 10.6, when we use the same template based on a format
of 30 characters and 27 lines on all our computers, we systematically get a
message saying :
Ce document formaté pour papier de taille " 12_n ", sur une
embosseuse non définie (" Embosseuse par défaut ").
Corriger ceci dans la boîte de dialogue " configuration de
l'embosseuse " du menu " Document " ; vous devez choisir une embosseuse et
une taille de papier d'au moins 27 lignes et 30 caractère pour éviter le
reformatage du document.
(see screenshot in attachment). this mesage is misleading
because it suggests that the document is ill-formated, which is not correct,
so it should be either removed or modified as a warning rather than an error
message.
Best regards
Yves
* * *
* This message is via list duxhelp at freelists.org.
* To unsubscribe, send a blank message with
* unsubscribe
* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
* subscribe, unsubscribe, and set vacation mode and other subscription
* options by visiting //www.freelists.org. The list archive
* is also located there.
* Duxbury Systems' web site is http://www.duxburysystems.com
* * *
Other related posts:
