Forum Graph100

J’utilise le C pour le développement de ce projet, je ne connais pas la POO.

Le faite que mon codage n’est pas a la norme ASCII me pause effectivement problème car impossible d’utilises les fonctions ou déclaration avec des string.
Je prévois donc de faire correspondre tous les caractères définis par l’ASCII  à ma police.
Ca me fait un peu chi… parce que tout est déjà créé avec Sprit Maker en utilisant des tableau de pointeurs, alors pour réarranger tout ça ……….

Merci pour ton aide.

Au final mon programme pourra ouvrir un fichier spécifique selon 2 modes :
-    Lecture (navigation rapide, défilement d’écran sans le curseur, marque page, sommaire…)
-    Ecriture (possibilité d’enregistrement, de modification…)   
Le basculement entre ces 2 modes pourra se faire à n’importe quel moment.
Lorsque un new fichier est créé il sera ouvert en écriture par défaut, lors de l’ouverture d’un fichier existant il sera en mode Lecture par défaut.

Pour les différents modes d’écritures je compte utiliser un c-lock à la manière de l’écriture CASIO.
Je ne pense pas que l’utilisation des touches multiple soit réellement utile pour un traitement de texte.
Pour ce qui est de l’interface entre l’utilisateur et le logiciel je prévois effectivement d’utiliser les touches les touches F1 à F6 de la façon suivante pour le mode écriture :
-     F1 Fichier :new,opern, save, save as, close
-    F2 Edition :cut, copy, past, select all
-    F3 Insertion de dessin
-    F4 Police : taille (uniquement en majuscule pour la grande), française, grec, symboles scientifique…
-    F5 Recherche
-    F6 Lecture <-> écriture
Les racourcits (Shift, Ctrl, Alpha mode, Nuneric mode)  sur le clavier seront conservé

et pour le mode lecture :
-    F1 jump : bottom, top
-    F2 sommaire
-    F3 je sais pô
-    F5 Recherche
-    F6 Lecture <-> écriture

Voila comment ç’était dans mon rêve !!!
Mais je sais bien qu’avant d’en arriver là la route est très longue et semé d’embûches et puis j’ai mes études…
Je commence maintenant mais ç’est surtout cet été que j’aurai le temps.

Mais ma conduite de projet est la suivante :
-    Prise en main des différentes librairies utilisées : fait
-    Création des sprites de la police avec les 3 niveau de gris : fait mais pas organisé dans l’ordre ASCII
-    Développement des fonctions d’entrées au clavier et d’affichage en gérant des index qui s’incrémente automatiquement pour les coordonnées (x, y) : J’en suis là !
-    Gestion des caractères par   liste chaînée avec allocation dynamique
-    Insertion de dessin et compression de l’image selon une méthode approprié (peut étre LZW)
-    développement de l’algo de compression (Huffman) de l’ensemble du fichier vers une mem zone.
-    Et en fin l’Interface utilisateur

Qu’en penssez vous ?
Tous les conseils sont les bien venus et si je me trompe sur un truck dites moi le…

Ca m’intéresserai beaucoup si tu codait la partie compression, si tu en as le temps bien sure.
Je vais t’envoyer un mail, pour te donner mon adresse mail afin que tu puisses m’envoyer ta librairie lorsque tu l’auras faite (je ne veux pas diffuser mon adresse sur Internet…).

En ce qui concerne le format du fichier généré vers la mem zone (sans prendre en considération la compression) je compte faire comme ça :

Par exemple
[Couleur noire]
[Petite police]   seulement après un code de retour a la ligne ou au début du fichier
[Code de C]
[Code de a]
[Code de s]
[Code de i]
[Code de o]
[Couleur gris clair]
[Code de espace]
[Code de G]
[Code de 1]
[Code de 0]
[Code de 0]
[Code de retour a la ligne]
[Grosse police]    seulement après un code de retour a la ligne ou au début du fichier
[Code de A]
[Code de B]
[Code de C]
[EOF]

ce qui donne lors du décodage:

Casio(en noir)_ G100(en gris clair)
ABC (toujours en gris clair)

Ces codes seront envoyé compressé vers la mem zone seulement lors d’un « save » ou « save as».
Les symboles sur plusieurs niveau prendrons 2 octés et les autres 1 octé

Je ne sait pas si ç’est a ce procédé que tu fait référence lorsque  tu parles de tags, si ç’est pas ça j’aurai besoin d’explications (avec des mots pas trop compliqué , je ne suis pas informaticien de formation mais électronicien… )

Pour ce qui est du chaînage ç’est seulement lorsque le fichier est chargé dans la RAM.
Ca permettra de le modifier, d’effacer, d’insérer  ou d’ajouter très facilement des caractères.

Pour le moment la forme général de mon algorigramme est sur ce principe, si je doit le modifier ç’est maintenant ou jamais.


Merci pour ton soutien.

Un caractère avant le save en mémoire correspondra à une structure du type

Struct caracter
{short value ;
struct caracter *next ;
}

Les entités du type struct seront créé dynamiquement mais faisons simple.
Par exemple un fichier de n caractère :

Struct caracter c1, c2, …..cn

J’initialiserai le pointeur « next » de la structure c1 pour pointer vers la structure c2
c1.next = &c2
La valeur « value » de c2 recevra le code du symbole à afficher

J’initialiserai le pointeur « next » de la structure c2 pour pointer vers la structure c3
c2.next = &c3
La valeur « value » de c3 recevra le code du second symbole à afficher

Ansi de suite jusque à cn

En fin pou cn, comme ç’est le dernier caractère, la valeur du pointeur « next » sera mis a 0 pour indiquer que ç’est la fin
cn.next = 0
Et « value » de cn recevra le code du dernier caractère

Chématiquement pour 3 caractéres ça sera comme ça :

c1
value [code du symbole c1]      c2
next   [pointeur vers c2]  ----value [code de c2]              c3
                                                 next  [pointeur vers c3]--value [code de c3]
                                                                                             next  [ 00 ]fin

À chaque structure créé j’aurai incrémenté une variable globale TAILLE qui indiquera la taille du fichier non compressé en utilisant :

TAILLE * Seizeof (short) ;   ou TAILLE * Seizeof (struct caracter) ;

Mais je ne sait pas si tu en aura réellement besoin car quand next = 0 ç’est la fin.
Quoi qu’il en soit je le ferais pour calculer le taux de compression

En ce qui concerne la compression :

Une foie que tu aura l’adresse du premier élément de la liste chaînée (c1) par l’intermédiaire d’un pointeur sur structure du type « caracter » tu n’aura qua suivre les rails, qui ne sont autre que « next », pour compresser les symboles donné par « value »
Sans oublier d’incrémenter un compteur pour connaître la taille afin de créer la mem zone.

Une fonction du type

Struct  fill_compresed      compress_Huffman    (long*fill_pas_compresé , long TAILL)
    {...   //compression en fonction de value et en suivant next
    }

avec

struct fill_compresed
{long taille ;
long *adresse_fill_compresed;
}

me parait corecte.

En ce qui concerne la décompression :

Le paramètre d’entrée serait une table de char qui est le nom du fichier basic que l’utilisateur veut décoder.
Tu n’auras qu’à décompresser selon le mode de la liste chaînée vue plus haut.
Et retourner un paramètre de sortie qui sera un pointeur sur structure du type « caracter » indiquant l’adresse de la structure correspondant au  premier symbole, soit c1.
Si une erreur c’est produit lors de l’exécution de la fonction de décompression le pointeur « next » devra être initialisé à 0 et « value » initialisé par un code relatif au type de l’erreur.

Donc :

Struct caracter       decompres_Huffman     (name_compreced_fill[8])
{......//chercher le fichier,le décompresser en le mettant sous la forme de liste chaîné
}

me semble bien.

Qu’est que t’en penses ?

MERDE CA MARCHE TOUJOUR PAS !!!!!!!!!!!!

PUTAin de MiSE EN page de MERDE :evil:    :evil:

En fin j'esper que t'as compris méme sans le "shematiquement"

Je crois qu'il s'énerve sur la mise en page du forum

Vi c'est effectivement + rentable de faire ça par bloc de texte, eventuellement tu marques pour chaque bloc le formatage

Heu...non,

la 2nd fefinition serait plutot :

Struct fill_compresed compress_Huffman (struct text_line *fill_pas_compresé )
{... //compression en fonction de « content » et en suivant « next »
}

Je te remercie pour ton aide.

PS : à partir de la semaine prochaine j'aurai accés à Internet seulement le weekend, donc ne t'étonne pas si je reponds pas tout de suite.

J'ai fait un projet pour les cours ya 3 ans dont le sujet était de faire une écriture intuitive genre téléphone portable
en gros le principe est qu'on commence à écrire le mot et qu'il propose tous les mots qui commencent par ce qu'on a écrit
une autre partie du projet consistait à implémenter huffman pour compresser le dictionnaire
c'est du C, voila mon projet :
http://embrun2002.free.fr/files/cours/p … up1-pp.tgz

j'espère que ça peut t'aider

Je te remercie pour ta documentation et tes codes sources Nykosledieu.
Ca sera très utile pour le développement de la lib de compression :P

Ne t’inquiète pas  Deather, ç’est pas urgent car la partie compression ç’est vers la fin du projet.
De plus, je vais être obligé de décrocher  (pas complètement, bien sure…) jusque a mi Juin.
Ça sera surtout cet été que je m’y consacrerai.

Par contre j’ai pensé à un truck :
Pour la décompression ne t’embéte pas avec la liste chaînée.
Met le fichier décompressé sous forme de table dans une mem zone.
Je le metrai moi-même sous  forme de chaînage avec une fonction qui ira lire dans cette mem zone.

Et pour la compression ça serait bien que tu mettes le fichier compressé directement dans la mem_zone spécifiée.

Ainsi, ça permettra d’éviter d’avoir a un moment quelconque la liste chaînée + le fichier compressé dans la RAM.

Donc je verrais bien :


//============  en global ===========
Struct text_line
{short* content;
unsigned short length;
srtuct text_line *preced;
struct text_line *next ;
}

//========== dans ta lib ============

int   compress_Huffman    (struct text_line *fill_pas_compresé , char name_ compreced_fill[8])
{int error ;
………
//compression en fonction de « content » et  « length » en suivant « next » vers « name_ compreced_fill[8} »  en essayant d’économiser au maximum la RAM
…..….
return (error) ;       //type d’erreur rencontrée
}


int      decompres_Huffman     (char name_compreced_fill[8], char name_decompressed_fill[8] )
{int error ;
……..
//chercher le fichier spesifié par « name_compreced_fill[8] » dans la mem zone
//le décompresser, tu peut utiliser toute la RAM que tu veut a condition qu’elle soit libérée a la fin de la routine de décompression.
//création de la mem zone spécifié par name_decompressed_fill[8]
//écriture dans cette dernière du tableau décompressé
............
return (error);   //type d’erreur rencontrée
}

En ce qui concerne les fichiers en tête j’utilises :

#include <dos.h>
#include "gxlib10.h"
#include "Casio2.h"     
Et bien sure memzones.c 1.06 a été ajouté au projet

Les fonctions que je n’utilise pas dans Casio2 et gxlib10 ont été mises en commentaires, y compris <stdio.h> et <string.h.> qui étaient dans Casio2

Je vais de m’en tenir là, en fin je vais essayer...
Donc utilise les mémes que moi.

hmmm un nouveau projet c'est bien ça. Et moi qui a toujour la lib memzone 2.0 dans mon placard... merestait juste la doc à faire, et une phase de test intense, même si ma version de Touche l'utilise déjà... C'est triste, tout ce que  je me souviens, c'est que maintenant les memzones s'accèdent et s'écrivent comme des fichiers sur disques...

ah tiens, en regardant dans le .h je vois que j'ai ajouté ces nouvelles fonctions:

MEMZ *mopen(const char ztype, const unsigned char *zonename, const char *mode);

size_t mwrite    (const void *ptr,   size_t element_size, size_t n, MEMZ *stream);

size_t mread    (void *ptr,        size_t element_size, size_t n, MEMZ *stream);

int mclose (MEMZ *stream);

int mseek (MEMZ *stream, unsigned offset, int whence);

#define simple_mseek(a,b) a->pointer=b

#define mrewind(a) a->pointer=0

#define munlink(a,b) create_mem_zone(a,b,0,DELETE_ZONE)

int mtruncate (MEMZ *stream, size_t newsize);

enfin bref, cette version est plus simple d'utilisation, pas de risque de dépassement de mémoire, ni d'erreur de pointeur, plus besoin de se préoccuper de rien, juste utiliser les fonctions ci-dessus...

Si ça vous intéresse dîtes le moi.


PS: le plus étrange avec la disparition des programmeurs G100 (ceux qui répondent ici en fait) c'est que l'intérêt pour nos programmes semblent toujours être aussi important, Touche par exemple est toujours téléchargé au moins une fois par jour... (et memzone a été téléchargé 11 fois au mois de mars).
Peut-être y'a t-il un autre forum G-100 ailleurs et on est pas au courant