Who's Online |
69 user(s) are online ( 38 user(s) are browsing Forums)
Members: 0
Guests: 69
more...
|
|
|
|
|
Re: HP LaserJet 2605dn,Postscript Height Issue
|
Posted on: 2007/3/5 11:27
#121
|
Just popping in 
|
@Swoop
IMHO passing the pagesize from AmiGS to GhostScript is already
done and the problem is that AmiGS has no idea about the pagesize.
To tell it about it, replace the first line of the PS file
("%!PS") with e.g.
%!PS-Adobe-3.0
%%DocumentMedia: a4 596 842 0 () ()
%%EndComments
and add a line
%%Page: 1 1
just before the first "newpath" line, then AmiGS will display
the width and height specified with the DocumentMedia comment
as paper size. The next version of the PostScript printer driver
will do that automatically.
Note, this fixes only the reported paper size of AmiGS,
not the wrong display of GhostScript, you also need to
apply the fix described in the previous comment for this.
|
|
|
|
|
|
Re: HP LaserJet 2605dn,Postscript Height Issue
|
Posted on: 2007/3/5 11:17
#122
|
Just popping in
|
@frak
To tell GhostScript (and maybe your printer too) that your
paper size is A4, print into a file, search the part which
specifies the paper size (when not in passthrough mode this
can be found by searching for "a4", then add
/setpagedevice where
{ pop 1 dict
dup /PageSize [ 596 842 ] put
setpagedevice
} if
The next version of the PostScript printer driver will
do that automatically.
When your printer understands PostScript level 2, its also
possible to change the line
/a4 {} def
in Devs:postscript_init.ps into
/a4 { << /PageSize [ 596 842 ] >> setpagedevice } def
then it should work without the need to manually edit each
PS file.
|
|
|
|
|
|
Re: HP LaserJet 2605dn,Postscript Height Issue
|
Posted on: 2007/3/4 11:44
#123
|
Just popping in
|
@frak Quote:
i've now set Printer PS to output US Letter instead of A4, The output is perfect.
Then your printer probably thought your paper would be US Letter. Quote:
I'm just guessing but i think anything set higher than US Letter won't come thru as ment...could you verify this theory in the code?
No, my current working theory is that the PostScript printer driver doesnt explicitly tell the printer which size its paper has, it assumes that the printer knows that by itself and tells it to print the picture scaled to absolute dimensions which of course fails when the printer is unaware of the physical size of the page and assumes it would be US Letter only, then it crops the image. In theory it should be possible to define the paper size in the output but in practice even AmiGS seems to ignore such a definition and always shows "Letter" as paper size here, hints how to properly define the paper size in the output in such a way that both AmiGS and a real printer understand it are welcome.
|
|
|
|
|
|
Re: HP LaserJet 2605dn,Postscript Height Issue
|
Posted on: 2007/3/3 19:54
#124
|
Just popping in
|
@frak Quote:
Font pitch pize (yes it says pize)
Fixed, thanks.
|
|
|
|
|
|
Re: HP LaserJet 2605dn,Postscript Height Issue
|
Posted on: 2007/3/3 19:39
#125
|
Just popping in
|
@frak
Are we talking about text printing or graphics printing?
And from which application?
The passthrough mode suggests that you are using an
application which already creates PostScript output
by itself, so maybe you have to set the correct page
size and borders inside that application.
Also your gfx settings (no scaling, no centering) seem
to suggest that it depends on the aspect ratio of the
source image which destination image height results
from it, and when the destination height is smaller than
the paper height the lower region remains white IMHO.
What happens when you print into a file (with
printtofile.device as printer port device set in Printer prefs)
and view that file with AmiGS? Has it the same idea about
borders as your printer? Anything in the output file which
looks wrong? PostScript is somehow readable by humans...
And what does your printer manual say about unprintable
borders?
|
|
|
|
|
|
Re: Mouse wheel support on classic programs
|
Posted on: 2007/2/28 7:50
#126
|
Just popping in
|
@Swoop Quote:
There is a C:IPrefs in S/Startup-Sequence, I presume I just add 'newmouse' after that.
Is it case sensitive?
Command line arguments are not case sensitive, however, when you select turkish as preferred language, you can choose between an international variant which behaves like other languages and a turkish variant which does turkish case comparison. The turkish case comparison routine handles i and I as different letters because a small letter i (with dot above) matches the capital letter I with dot above and the small letter dotless i matches the capital letter I (without dot above). But for IPrefs this doesnt matter anyway because when IPrefs is started the preferred language is still english. All shell scripts started after IPrefs may get problems when using lowercase keywords which contain an "i" when running on a turkish machine, shell script writers are encouraged to always use uppercase for keywords...
|
|
|
|
|
|
Re: HP LaserJet
|
Posted on: 2007/2/27 20:12
#127
|
Just popping in
|
@FuZion
Is the printer attached to a self-powered (not bus-powered)
USB hub? Without such a hub USB on A1 may be unstable (it provides
not as much power as may be needed by some device).
Another possible cause for the problem is an old bug in all
HP drivers which was detected after release of OS4Final.
But until now this was not reported to cause crashes with
usbprinter.device, only with a1parallel.device in some
cases.
|
|
|
|
|
|
Re: HP LaserJet
|
Posted on: 2007/2/27 19:47
#128
|
Just popping in
|
@tonyw
You asked for a PCL 5e printer driver?
Just checked the releasenotes of the OS3.9 NDK:
HP_LaserJet 44.6 (21.8.99)
[...]
- Now allows for 600 DPI graphics printing with densities
5, 6 and 7. Note that this requires a PCL 5e compliant
printer, such as the LaserJet 4.
|
|
|
|
|
|
Re: HP LaserJet
|
Posted on: 2007/2/27 12:38
#129
|
Just popping in
|
@FuZion
From here this looks as if you used the PostScript printer
driver with a printer that doesnt understand PostScript
(ergo it prints it as text).
|
|
|
|
|
|
Re: Where is the SDK?
|
Posted on: 2007/2/19 13:32
#130
|
Just popping in
|
@abalaban
It seems those SysList functions dont exist and adding
such a description to the autodoc was a mistake, the current
autodoc doesnt mention such functions anymore, the example
uses Forbid().
|
|
|
|
|
|
Re: Where is the SDK?
|
Posted on: 2007/2/18 13:43
#131
|
Just popping in
|
@abalaban This was already fixed in V52.2 of CatComp.doc some days before, now it looks like Quote:
- "rcsid" lets you specify a version string using the standard RCS method.
That way, versions of catalogs can get updated automatically by RCS.
- "name" can be used in conjunction with the "rcsid" command to specify
the name component of a 2.0 version string. For example:
## rcsid $Date: 2007/02/05 15:52:21 $ $Revision: 1.13 $
## name myprogram.catalog
The above will embed "$VER: myprogram.catalog 1.13 (5.2.2007)" inside of the
message catalog.
The problem is that CVS modifies the rcsid part od the file each time an update is checked in, so dont wonder when minor glitches (wrong revision or date) will appear again in future 
|
|
|
|
|
|
Re: Where is the SDK?
|
Posted on: 2007/2/16 11:54
#132
|
Just popping in
|
@glames Quote:
When I launch SDK/C/sh, if I enter a "dir" then I have a DSI error.
IIRC that was a .rodata write bug which is fixed in the meantime, search for an update of "abc-shell".
|
|
|
|
|
|
Re: Where is the SDK?
|
Posted on: 2007/2/16 10:49
#133
|
Just popping in
|
@ZeroG Quote:
checkbox_gc.doc: GA_Selected method OM_GET is missing.
Just fixed it, thanks.
|
|
|
|
|
|
Re: Where is the SDK?
|
Posted on: 2007/2/16 10:35
#134
|
Just popping in
|
@ZeroG Quote:
devices/prtbase.h: strange functionpointers in struct PrinterExtendedData.
Quote:
VOID ped_Init(void)
VOID ped_Expunge(void)
LONG ped_Open(void)
VOID ped_Close(void)
In the Comments of the pointers:
Quote:
LONG ped_Init(struct PrinterData * pd)
VOID ped_Expunge(VOID)
LONG ped_Open(struct printerIO * ior)
VOID ped_Close(struct printerIO * ior)
And finally in the Printerdriver Example from the NDK3.9:
Quote:
VOID DriverExpunge(VOID)
VOID DriverInit(struct PrinterData * pd)
VOID DriverClose(struct printerIO *ior)
LONG DriverOpen(struct printerIO *ior)
Well, those strange function pointers probably date back to the ancient times where non-ANSI C compilers had still to be supported (which dont accept parameter lists here). Replacing them with those from the comments is also not possible, those are broken too, the guy who defined them probably didnt notice that there doesnt exist a "struct printerIO" anywhere in AmigaOS (only a "union printerIO"), and that only old compilers wont complain about nonexisting structures in parameter lists of a function pointer declaration. To complicate it even more, those function pointers dont use register arguments but stack arguments, and to finally confuse you, they may point to PPC code which expects arguments passed as defined in the SysV ABI. In the current version of the include file, the function pointers are still declared without arguments, just to force everybody to use proper casts, and the following comments are present: Quote:
A note on the function pointers in these data structure definitions:
unless otherwise specified, all functions expect that their parameters
are passed on the *stack* rather than in CPU registers. Every parameter
must be passed a 32 bit long word, i.e. an "UWORD" will use the same
stack space as an "ULONG".
When the printer driver is PPC native, the function pointers will
point to PPC native functions, otherwise to 68K stubs or functions.
[...]
When the printer driver is PPC native, the function pointers
point to PPC native functions.
[...]
/* called after LoadSeg, returns zero for success:
*
* LONG ped_Init(struct PrinterData * pd);
*/
[...]
/* called before UnLoadSeg:
*
* VOID ped_Expunge(VOID);
*/
[..]
/* called at OpenDevice, returns zero for success:
*
* LONG ped_Open(struct printerIO * ior);
*/
[..]
/* called at CloseDevice:
*
* VOID ped_Close(struct printerIO * ior);
*/
[...]
Starting with printer.device 51.12 PPC native printer drivers
are supported. Those must contain a global symbol "PrinterSegment"
which defines the start of the struct PrinterSegment, to keep this
in the binary, driver writers can call "strip -KPrinterSegment ...".
and the driver example source contains Quote:
LONG SAVEDS STDARGS
DriverInit(struct PrinterData * pd)
[...]
VOID SAVEDS STDARGS
DriverExpunge(VOID)
[...]
LONG SAVEDS STDARGS
DriverOpen(union printerIO *ior UNUSED)
[...]
VOID SAVEDS STDARGS
DriverClose(union printerIO *ior UNUSED)
which allows to build both 68k and PPC drivers.
|
|
|
|
|
|
Re: Where is the SDK?
|
Posted on: 2007/2/15 19:33
#135
|
Just popping in
|
@Hans Quote:
Just add a note about the VARARGS68k thing and point to the OS4 migration guide
Done, thanks.
|
|
|
|
|
|
Re: Where is the SDK?
|
Posted on: 2007/2/15 17:37
#136
|
Just popping in
|
@Hans Quote:
Actually, I now have one thing that could be clarified
in the documentation. I had some trouble using
ILocale->FormatString() because I was using varargs.
It seems that the PowerPC version of AmigaOS has two
versions of varargs, the standard one and
va_startlinear()/va_getlinearva().
You also have to use the VARARGS68K macro.
Why this extra complication? Mentioning it in the
documentation somewhere would be helpful.
The SDK:Documentation/Developer Info/General/os4_migration_guide.pdf file explains that the varargs handling of the PPC SysV ABI is incompatible to the varargs handling of the 68k. It also explains that VARARGS68K has to be used when backwards compatibility is needed. All OS4 system functions are declared with the VARARGS68K attribute in the <include/interfaces/something.h> files so I thought it would be common knowledge that the "normal" C varargs handling cant be used with any existing OS4 system function. Suggestions how to modify the existing doc Quote:
dataStream - a stream of data that is interpreted according to
the format string. Often this is a pointer into
the task's stack.
are welcome
|
|
|
|
|
|
Re: OS4 missing parts?
|
Posted on: 2007/2/14 10:29
#137
|
Just popping in
|
@rwo Quote:
Fake? no I have no clue what you are hintting at!
Start TypeManager, click on CGTimes, click on Modify, click on the Files tab, have a look at the font file gadget, it tells you that the raw font file is not CGTimes.type (interpreted by bullet.library) anymore but FONTS:_truetype/DejaVuSerif.ttf (interpreted by ft2.library). The advantage is that CGTimes now contains an Euro sign :)
|
|
|
|
|
|
Re: Turboprint and saved preferences
|
Posted on: 2007/2/14 10:12
#138
|
Just popping in
|
@Raziel
I've ported all OS4 printer drivers to PPC except PRINTERS:File
where I dont have the sourcecode. In the past creating printer
drivers for AmigaOS was a third-party-job, I dont think that it
makes sense that the OS4 developers waste their time with writing
printer drivers (AFAIK there exist lots of printers...) when
neither the printer manufacturers nor third-party commercial
developers do that.
You should ask for an update of TurboPrint or Studio IMHO,
or use PostScript or PCL printers. When your PCL printer
has features which are not supported by an OS4 printer driver
yet, feel free to modify the public PCL printer driver source
code (NDK 3.9, will be updated in the next OS4 SDK) or to
search a developer which does it for you.
|
|
|
|
|
|
Re: Turboprint and saved preferences
|
Posted on: 2007/2/13 19:18
#139
|
Just popping in
|
@sundown Quote:
Another thing I found was if I config Printer prefs then
config TP, my Printer prefs changes or if I config TP,
my Printer prefs changes. In other words the 2 pref
settings interact.
TP creates printer.prefs and printergfx.prefs files in OS3.1(!) format, the OS4Final printer prefs editor didnt accept such old settings files anymore, the OS3.5 format was minimum. Changed that, from the releasenotes: Quote:
Printer 52.3 (30.1.2007) (dwuerkner)
- For backwards compatibility to TurboPrint V7, old OS3.1(!) prefs files
created by TurboPrint where the PGFX IFF chunk was stored in a separate
file and where the PDEV IFF chunk was missing are accepted for unit 0.
This avoids falling back to default prefs after calling NoTurbo.
|
|
|
|
|
|
Re: Own up... who broke the UK locale?
|
Posted on: 2007/2/5 10:32
#140
|
Just popping in
|
@drHirudo Quote:
Hmmm, the problem as I see it is that when using the standart AmigaOS 4 bulgarian locale it produces characters with different ASCII codes than the standart ones.
When I typed with IBrowse in the google search bar some text it returned something like this:
Quote:
Your search - ?????? - did not match any documents.
This depends on your definition of "standard". The OS4 bulgarian locale uses the ISO-8859-5 standard, the bulgarian department of Google uses the windows-1251 standard. IBrowse seems to be unable to use any other charset than the current system default charset in its MUI GUI, probably because MUI doesnt support charsets, so you see ISO-8859-5 characters in the MUI string gadget when typing text but Google expects windows-1251 characters and IBrowse seems to miss to tell Google about the charset of the text you typed (or the protocol doesnt allow this). I've written an Amiga-1251 version of the bulgarian language driver which should work around this problems, as already written in PM, I'd need your EMail address to send it to you for testing.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
