Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

کوتاه سازی مسیرهای منتهی به فونت ها #303

Open
PerseusTheGreat opened this issue Feb 21, 2023 · 0 comments
Open

Comments

@PerseusTheGreat
Copy link

PerseusTheGreat commented Feb 21, 2023

سلام.
خواهشمندم مسیر ها و نام فونت ها را خلاصه سازی نماید.
مسیرهای ساخته شده برای دستیابی به فونت ها طولانی هستند.
اگر مسیر پروژه هایی که از فونت شما استفاده میکنند، خود نیز طولانی باشد، بسته به سیستم عامل، مرورگرها رفتارهای متفاوتی دارند.

بطور مثال در ویندوز حداکثر طول قابل تشخیص برای مسیرهای ختم شده به یک فایل، شامل نام درایو، نام پوشه ها، نام فایل، و کاراکترهای جدا کننده، 260 کاراکتر میباشد و برای فعال سازی مسیرهای طولانی تر، باید Registry ویندوز دست کاری شود که خب هر کاربری دانش این کار را ندارد.
سند رسمی از مایکروسافت Maximum Path Length Limitation

به تصویر ذیل توجه فرمایید:
vm
بنده قصد دارم پکیج npm رسمی قلم شما را به پروژه ای بیافزایم.
برای نسخه RD-UI-FD-NL که مناسب ترین نسخه برای نرم افزارهای مبتنی بر وب میباشد، طول مسیر از پوشهء ریشه پروژه برابر است با:
26 + (10+1) + (4+1) + (25+1) + (5+1) + (8+1) + 38 = 121 کاراکتر.
فرض کنید آدرس پوشه پروژه بنده نیز به دلیل تو در تویی پوشه هایی که جهت طبقه بندی پروژه بکار برده ام، دارای طولی بیش از 140 کاراکتر باشد.
در نتیجه به طول 261 میرسیم و مرورگرهای مبتنی بر ویندوز، همه شان، فایل فونت را در اجرای local تشخیص نمیدهند.
بنابراین امثال بنده مجبور میشوند آدرس های پروژه های شان را روی استوریج محلی طوری تنظیم کنند که این مشکل پیش نیاید.
این مسئله شاید در پروژه های شخصی به راحتی انجام شود ولی در پروژه های سازمانی، دیسیپلین های کدنویسی ممکن است مانع این موضوع باشد.

ممکن است شما بفرمایید که چه ربطی دارد، آدرس دهی در مرورگر به صورت نسبی تنظیم میشود که فرمایش صحیحی است، البته به شرطی که پروژه مبتنی بر یک نرم افزار وب-سرور محلی سرو شود.
اگر فایل html مربوطه را مستقیم (با دابل کلیک یا درگ اند دراپ) در مرورگر اجرا کنیم، مرورگر، آدرس های نسبی فونت ها را بر اساس آدرس فیزیکی فایل html روی استوریج محلی، میسازد و اگر این آدرس ها بیش از 260 کاراکتر شوند، فونت ها را بارگذاری نمیکند.
اگر لطف کنید و ساختار پوشه های حاوی فونت ها را ساده سازی و کوتاه کنید این مشکل اتفاق نخواهد افتاد.

بطور مثال چنین ساختاری را ملاحظه بفرمایید:

Root
│   AUTHORS.txt
│   CHANGELOG.md
│   OFL.txt
│   README.md
│   راهنما.txt
└───dist
    ├───base
    │   ├───ttf
    │   ├───var
    │   └───web
    ├───misc
    │   ├───FD
    │   │   ├───ttf
    │   │   ├───var
    │   │   └───web
    │   ├───FDNL
    │   │   ├───ttf
    │   │   ├───var
    │   │   └───web
    │   └───NL
    │       ├───ttf
    │       ├───var
    │       └───web
    ├───UI
    │   ├───base
    │   │   ├───ttf
    │   │   ├───var
    │   │   └───web
    │   └───misc
    │       ├───FD
    │       │   ├───ttf
    │       │   ├───var
    │       │   └───web
    │       ├───FDNL
    │       │   ├───ttf
    │       │   ├───var
    │       │   └───web
    │       └───NL
    │           ├───ttf
    │           ├───var
    │           └───web
    └───RD
        ├───base
        │   ├───ttf
        │   ├───var
        │   └───web
        ├───misc
        │   ├───FD
        │   │   ├───ttf
        │   │   ├───var
        │   │   └───web
        │   ├───FDNL
        │   │   ├───ttf
        │   │   ├───var
        │   │   └───web
        │   └───NL
        │       ├───ttf
        │       ├───var
        │       └───web
        └───UI
            ├───base
            │   ├───ttf
            │   ├───var
            │   └───web
            └───misc
                ├───FD
                │   ├───ttf
                │   ├───var
                │   └───web
                ├───FDNL
                │   ├───ttf
                │   ├───var
                │   └───web
                └───NL
                    ├───ttf
                    ├───var
                    └───web

در هر پوشه حاوی یک نسخه متفات نیز ساختار بدین شکل خواهد بود:

base
│   AtFontFace.css
├───ttf
│       100-Thin.ttf
│       200-ExtraLight.ttf
│       300-Light.ttf
│       400-Regular.ttf
│       500-Medium.ttf
│       600-SemiBold.ttf
│       700-Bold.ttf
│       800-ExtraBold.ttf
│       900-Black.ttf
├───var
│       wght.ttf
└───web
        100-Thin.woff2
        200-ExtraLight.woff2
        300-Light.woff2
        400-Regular.woff2
        500-Medium.woff2
        600-SemiBold.woff2
        700-Bold.woff2
        800-ExtraBold.woff2
        900-Black.woff2
        wght.woff2

حتی میتوانید اسامی فایل ها را نیز کوتاه تر بنویسید:

base
│   vmaff.css
├───ttf
│       100.ttf
│       200.ttf
│       300.ttf
│       400.ttf
│       500.ttf
│       600.ttf
│       700.ttf
│       800.ttf
│       900.ttf
├───var
│       wght.ttf
└───web
        100.woff2
        200.woff2
        300.woff2
        400.woff2
        500.woff2
        600.woff2
        700.woff2
        800.woff2
        900.woff2
        wght.woff2

خواهشمندم به این موضوع بیاندیشید.
توسعه دهندگان میتوانند چنین ساختاری را پیاده کنند ولی هر زمان که نسخه جدید فونت ارائه شود، میبایست این ساختار را مجددا ایجاد کنند که کار پر دردسر و خطا افزایی میباشد.
میتوانید همین نسخه را با بدون تغییر در فونت ها، با یک شماره ریویو (بطور مثال 33.0.3-rev1)، در npm مجددا منتشر نمایید.
شماره ریویو با استاندارد SemVer 2.0 تطابق دارد و در npm پشتیبانی میشود.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant