Re: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour

[Andrzej P. Wozniak]

From: Viktor Szakáts 
Sent: Saturday, February 20, 2010 3:22 AM
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour

> Hi Andrzej,
>
>> From:  
>>
>>> Revision: 13878
>> [...]
>>>  * contrib/hbwin/hbwin.ch
>>>* Changed to use full (0xFF) color components for RGB presets.
>>
>> Viktor, this change is incompatible with Clipper. Previous colours
>> were too dark, but 0xFF should stand for BRIGHT colours. Clipper uses
>> RGBI palette, see here:
>> * 4-bit RGBI palettes for explanation:
>> http://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#4-bit_RGBI
>> * EGA colour palette for hex values in implementation:
>> http://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter#The_EGA_color_palette
> Clipper had no graphical printing, nor any special color
> printing support for that matter,

RGBI palette is NOT for printing. I did NOT mention about printing at all.

> nor did it determine the
> actual colors that appeared on screen, so it's by no means
> a Clipper compatibility issue.

Clipper did NOT define any *own* palette, it just used CGA palette available
in DOS. The palette is used as CGA compatibility palette in EGA/VGA/Windows
till now.

> If you mean to mimic MS-DOS (or rather VGA/EGA) screen colors
> in Windows printing, I can't see strong reason why this would
> be desired.

I am not DTP professional, but I know at least two facts:
* You cannot mix RGB and CMYK colour models. RGB is for screen, CMYK is for
printing. All RGB_* #defines are in RGB colour model, so they are not to be
used for printing. See: http://en.wikipedia.org/wiki/RGB_color_model
* There is no simple colour conversion from RGB to CMYK. See:
http://en.wikipedia.org/wiki/CMYK_color_model#Conversion

As you already know, Clipper did NOT define any print colours and did NOT
use any known printing colour palette. We can use system colour management
(see ) or define our own
colour conversion scheme, but the palette should contain all 16 colours,
normal and BRIGHT.

> --- (from old hbwin.ch)
> #define RGB_BLACK  RGB( 0x00, 0x00, 0x00 )
> #define RGB_BLUE   RGB( 0x00, 0x00, 0x85 )
> #define RGB_GREEN  RGB( 0x00, 0x85, 0x00 )
> #define RGB_CYAN   RGB( 0x00, 0x85, 0x85 )
> #define RGB_REDRGB( 0x85, 0x00, 0x00 )
> #define RGB_MAGENTARGB( 0x85, 0x00, 0x85 )
> #define RGB_BROWN  RGB( 0x85, 0x85, 0x00 )
> #define RGB_WHITE  RGB( 0xC6, 0xC6, 0xC6 )
> ---

Once again, the above colours are in RGB colour model. They are defined for
display, not for printing. That is not full Clipper colour palette, only
non-BRIGHT part, and brown defined here is not brown on screen.

> F.e. why isn't "white" 0x85/0x85/0x85 to be consistent
> with other colors, or even more, why isn't it pure white:
> 0xFF/0xFF/0xFF, instead of being grey? :)

I DID write and you DID quote: "Previous colours were too dark", that's
why they are inconsistent.
I DID also write "0xFF should stand for BRIGHT colours", that's why
white is really light grey. And I know that real white may be darker
then the displayed one[1].
I linked also the explanation, why brown setting should be inconsistent,
did you read it?

I don't know why someone used such RGB values for the old colours – maybe
he/she picked them from his/her own display or corrected them as CGA colours
were too bright in his/her opinion. Still they are colours defined in RGB
colour model, that is – for display, not for printing.

[1] A good example for troubles with colour conversion for "red" and "white"
you can see here:
http://en.wikipedia.org/wiki/Flag_of_Poland#Design
http://en.wikipedia.org/wiki/File:Flag_of_Poland.svg
http://commons.wikimedia.org/wiki/File:Flag_of_Poland_(normative).svg
Maybe on your screen you cannot see differences between the flag and the
background colour in any places, but they are. Use some colour picker to
check RGB codes or use some good old CRT monitor.

-- 
Regards from The Harbour Project mirror in Poland
Andrzej P. Woźniak




--
Hosting 2GB za 40 zl brutto 
http://www.klatka.pl

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour

[Andrzej P. Wozniak]

From:  
Sent: Monday, February 15, 2010 12:14 PM
Subject: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour

> Revision: 13878
[...]
>   * contrib/hbwin/hbwin.ch
> * Changed to use full (0xFF) color components for RGB presets.

Viktor, this change is incompatible with Clipper. Previous colours were too
dark, but 0xFF should stand for BRIGHT colours. Clipper uses RGBI palette,
see here:
* 4-bit RGBI palettes for explanation:
http://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#4-bit_RGBI
* EGA colour palette for hex values in implementation:
http://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter#The_EGA_color_palette

-- 
Regards from The Harbour Project mirror in Poland
Andrzej P. Woźniak




--
Hosting 2GB za 40 zl brutto 
http://www.klatka.pl

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[13306]trunk/harbour/contrib/hbqt

[Andrzej P. Wozniak]

Sent: Saturday, December 19, 2009 11:03 AM; From: Viktor Szakáts


> Hi Pritpal,
>
> Please always include a short entry in ChangeLog about
> regeneration:
[...]

Hi Viktor,

Please never quote full list of changes, especially the list of regenerated
sources.

-- 
Regards from The Harbour Project mirror in Poland
Andrzej P. Woźniak




--
Darmowe statystyki stron www
http://WEBstat.pl

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[13234] trunk/harbour

[Andrzej P. Wozniak]

Sent: Wednesday, December 16, 2009 11:20 PM; From: Viktor Szakáts

> Hi Andrzej,
>
> We're interfacing with Windows MAPI, and IMO such
> limits and other RFC details should be enforced by
> its low level code.
[...]
> I can easily restore now any artificial limit if we
> don't trust MAPI to combat spam and conform with RFC.
> Anyhow I think this is not this _wrappers_ job, and
> removing any limit actually added value to it.


Thanks for the clarification, Viktor. It should be included in the
documentation, I think.

-- 
Regards from The Harbour Project mirror in Poland
Andrzej P. Woźniak




--
Darmowe statystyki stron www
http://WEBstat.pl

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Internet standards and Harbour

[Andrzej P. Wozniak]

Here are some remarks how to use Internet standards in programming and
documentation.

RFC
===

The only source for internet standards (RFC) is IETF and the website
ietf.org. You can get all the RFCs here: ftp://ietf.org/rfc/ and all current
drafts here:
ftp://ietf.org/internet-drafts/

For example:
ftp://ietf.org/rfc/rfc-index.txt - list of all RFCs and their status
ftp://ietf.org/rfc/std-index.txt  - list of all standard track RFCs
ftp://ietf.org/rfc/RFCs_for_errata.txt - list of all RFCs with errata

ftp://ietf.org/rfc/rfc4180.txt - Common Format and MIME Type for
Comma-Separated Values (CSV) (Status: INFORMATIONAL)
ftp://ietf.org/rfc/rfc1855.txt  - Netiquette Guidelines (Status:
INFORMATIONAL)

ftp://ietf.org/rfc/rfc5321.txt - Simple Mail Transfer Protocol (SMTP) (see
errata)
ftp://ietf.org/rfc/rfc5322.txt - Internet Message Format (see errata)
ftp://ietf.org/rfc/rfc5246.txt - The Transport Layer Security (TLS) Protocol
Version 1.2 (see errata)

ftp://ietf.org/rfc/rfc3977.txt - Network News Transfer Protocol (NNTP) (see
errata)
ftp://ietf.org/rfc/rfc5536.txt - Netnews Article Format (Usenet posts)
ftp://ietf.org/rfc/rfc5537.txt - Netnews Architecture and Protocols (Usenet
groups)
ftp://ietf.org/internet-drafts/draft-ellermann-news-nntp-uri-11.txt - The
'news' and 'nntp' URI Schemes (to be RFC5538)

RFC errata listing is generated here (ordered by RFC ids, 3 MB now):
http://www.rfc-editor.org/errata_list.php

For software developing only the current RFCs should be used, Non-standard
solutions or obsoleted standards (eg. RFC 822 or RFC 2822) should be used
only for compatibility reasons and clearly documented.

Note that there are some unstandardized extensions in common use, such as
PGPVERIFY mentioned in RFC 5537.

Character sets
==
The names for charsets/codepages are registered by IANA here:
http://www.iana.org/assignments/character-sets
Note that the only names for Unicode charsets are written with dash (or
standard ASCII hyphen/minus in text/plain): UTF-7, UTF-8, UTF-16, UTF-32.
Only these names should be used in documentation. Use them also in
developing whenever it is possible. Any other names (e.g. UTF8) should be
used only for compatibility reasons and clearly documented.

Microsoft naming convention use names:
OEM - for DOS codepages (IANA registered IBMnnn, CPnnn charsets)
ANSI - for Windows codepages (IANA registered windows- charsets)
   (letter A as the last letter in function name)
WIDE - for UTF-16 charset (letter W as the last letter in function name)
Only these names should be used in documentation.

Note that "Unicode" name should never be used as a synonym for "UTF-16".

-- 
Regards from The Harbour Project mirror in Poland
Andrzej P. Wozniak




--
Darmowe statystyki stron www
http://WEBstat.pl

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[13234] trunk/harbour

[Andrzej P. Wozniak]

From:  
Sent: Sunday, December 13, 2009 2:49 PM
Subject: [Harbour] SF.net SVN: harbour-project:[13234] trunk/harbour

> Revision: 13234
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13234&view=rev
> Author:   vszakats
> Date: 2009-12-13 13:49:14 + (Sun, 13 Dec 2009)
>
> Log Message:
> ---
> 2009-12-13 14:46 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
>   * contrib/hbwin/mapi.c
> + Added support for unlimited number of recipients and
>   attached files. Please test and review.

Viktor, did you read RFC 5321 carefully, especially the section quoted
below?

/
4.5.3.1.8.  Recipients Buffer

   The minimum total number of recipients that MUST be buffered is 100
   recipients.  Rejection of messages (for excessive recipients) with
   fewer than 100 RCPT commands is a violation of this specification.
   The general principle that relaying SMTP server MUST NOT, and
   delivery SMTP servers SHOULD NOT, perform validation tests on message
   header fields suggests that messages SHOULD NOT be rejected based on
   the total number of recipients shown in header fields.  A server that
   imposes a limit on the number of recipients MUST behave in an orderly
   fashion, such as rejecting additional addresses over its limit rather
   than silently discarding addresses previously accepted.  A client
   that needs to deliver a message containing over 100 RCPT commands
   SHOULD be prepared to transmit in 100-recipient "chunks" if the
   server declines to accept more than 100 recipients in a single
   message.
\

How do you manage 100-recipient chunks? To prevent spamming, many free 
accounts have even non-standard restrictions, e.g. 20 emails per hour.

-- 
Regards from The Harbour Project mirror in Poland
Andrzej P. Wozniak



--
Darmowe statystyki stron www
http://WEBstat.pl

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Why harbour is name of this project?

[Andrzej P. Wozniak]

From: Massimo Belgrano <[EMAIL PROTECTED]>
Sent: Wt, 6 maja 2008 11:48
Subject: RE: [Harbour] Why harbour is name of this project?

> Is correct this page?
> http://en.wikipedia.org/wiki/Harbour_%28software%29#History

No. Massimo, no. It is a very bad writing style and there are many
commercial links.
Let me (and maybe someone else) correct your editions, please.

-- 
Regards from The Harbour Project mirror in Poland
Andrzej P. Wozniak
http://en.wikipedia.org/wiki/User:Andrzej_P._Wozniak



---
Darmowe konta email
   http://www.free.os.pl
  Pojemnosc 1 GB
---


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour