Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Windows API
  4. printing vertical text using ExtTextOut in memory DC

printing vertical text using ExtTextOut in memory DC

Scheduled Pinned Locked Moved Windows API
graphicsperformancehelp
4 Posts 3 Posters 13 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    abrahamlincolng
    wrote on last edited by
    #1

    I am using ExtTextOut to print unicode characters in memory DC. We create font using CreateFontIndirect to print characters in different orientations. When we use GB2312_CHARSET (chinese character set) with lfEscapement/orientation set to 270 degrees the characters are printed in reverse order. If the character to be printed is 'Chinese', it is printed as 'esenihc'. The same character set works fine if lfEscapement/orientation is set to 0 deg. The issue is present only in WINCE. The same code works fine in a Win32 application. I have written a sample application.Find below the code from sample app

    CSampView::OnDraw (CDC* pDisplayDC)
    {

    HDC hDC = CreateCompatibleDC(NULL);
    HBITMAP hBmp = CreateCompatibleBitmap(hDC, width, height);
    BITMAPINFO biBitmapInfo;

    // font size may vary if screen resolution changes
    biBitmapInfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
    biBitmapInfo.bmiHeader.biWidth = 500;
    biBitmapInfo.bmiHeader.biHeight = 500;
    biBitmapInfo.bmiHeader.biPlanes = 1;
    biBitmapInfo.bmiHeader.biBitCount = 1 ;
    biBitmapInfo.bmiHeader.biCompression = BI_RGB;
    biBitmapInfo.bmiHeader.biSizeImage = 0;
    biBitmapInfo.bmiHeader.biXPelsPerMeter = 0;
    biBitmapInfo.bmiHeader.biYPelsPerMeter = 0;
    biBitmapInfo.bmiHeader.biClrUsed = 0;
    biBitmapInfo.bmiHeader.biClrImportant = 0;
    biBitmapInfo.bmiColors[0].rgbBlue = 0;
    biBitmapInfo.bmiColors[0].rgbGreen = 0;
    biBitmapInfo.bmiColors[0].rgbRed = 0;
    biBitmapInfo.bmiColors[1].rgbBlue =1;
    biBitmapInfo.bmiColors[1].rgbGreen = 1;
    biBitmapInfo.bmiColors[1].rgbRed = 1;

    CDC *pDC = CDC::FromHandle(hDC);
    /*TCHAR szString[255] = {0x0043, 0x0068, 0x0069, 0x006E, 0x0065, 0x0073, 0x0065, 0x003A, 0x0020, 0x96C5,
    0x864E, 0x641C, 0x661F, 0x575A, 0x51B3, 0x5426, 0x8BA4, 0x80E1, 0x6208, 0x63A5,
    0x62CD, 0x96C5, 0x864E, 0x5E7F, 0x544A };*/

    wchar_t szString[255] = _T("Print Test");

    PUINT8 pui8ImageContent;
    // Create rendering canvas
    HBITMAP hBmp1 = CreateDIBSection(hDC,
    &biBitmapInfo,
    DIB_PAL_COLORS,
    (void**)&pui8ImageContent,
    NULL,
    0);

    HBITMAP holdObj = (HBITMAP)SelectObject(hDC, hBmp1);
    if (NULL == holdObj)
    {
    AfxMessageBox(L"Bitmap Selection failed");
    }
    CBitmap* aBMP = CBitmap::FromHandle(hBmp);
    BITMAP* abmpDim = NULL;
    aBMP->GetBitmap(abmpDim);

    memset(pui8ImageContent, 0, m_iOverallSizeInBytes);

    LOGFONT SLogFont = {0};
    memset(&SLogFont, 0, sizeof(LOGFONT));
    SLogFont.lfHeight = 50;
    SLogFont.lfWidth = 50;
    SLogFont.lfCharSet = GB2312_CHARSET

    A P 2 Replies Last reply
    0
    • A abrahamlincolng

      I am using ExtTextOut to print unicode characters in memory DC. We create font using CreateFontIndirect to print characters in different orientations. When we use GB2312_CHARSET (chinese character set) with lfEscapement/orientation set to 270 degrees the characters are printed in reverse order. If the character to be printed is 'Chinese', it is printed as 'esenihc'. The same character set works fine if lfEscapement/orientation is set to 0 deg. The issue is present only in WINCE. The same code works fine in a Win32 application. I have written a sample application.Find below the code from sample app

      CSampView::OnDraw (CDC* pDisplayDC)
      {

      HDC hDC = CreateCompatibleDC(NULL);
      HBITMAP hBmp = CreateCompatibleBitmap(hDC, width, height);
      BITMAPINFO biBitmapInfo;

      // font size may vary if screen resolution changes
      biBitmapInfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
      biBitmapInfo.bmiHeader.biWidth = 500;
      biBitmapInfo.bmiHeader.biHeight = 500;
      biBitmapInfo.bmiHeader.biPlanes = 1;
      biBitmapInfo.bmiHeader.biBitCount = 1 ;
      biBitmapInfo.bmiHeader.biCompression = BI_RGB;
      biBitmapInfo.bmiHeader.biSizeImage = 0;
      biBitmapInfo.bmiHeader.biXPelsPerMeter = 0;
      biBitmapInfo.bmiHeader.biYPelsPerMeter = 0;
      biBitmapInfo.bmiHeader.biClrUsed = 0;
      biBitmapInfo.bmiHeader.biClrImportant = 0;
      biBitmapInfo.bmiColors[0].rgbBlue = 0;
      biBitmapInfo.bmiColors[0].rgbGreen = 0;
      biBitmapInfo.bmiColors[0].rgbRed = 0;
      biBitmapInfo.bmiColors[1].rgbBlue =1;
      biBitmapInfo.bmiColors[1].rgbGreen = 1;
      biBitmapInfo.bmiColors[1].rgbRed = 1;

      CDC *pDC = CDC::FromHandle(hDC);
      /*TCHAR szString[255] = {0x0043, 0x0068, 0x0069, 0x006E, 0x0065, 0x0073, 0x0065, 0x003A, 0x0020, 0x96C5,
      0x864E, 0x641C, 0x661F, 0x575A, 0x51B3, 0x5426, 0x8BA4, 0x80E1, 0x6208, 0x63A5,
      0x62CD, 0x96C5, 0x864E, 0x5E7F, 0x544A };*/

      wchar_t szString[255] = _T("Print Test");

      PUINT8 pui8ImageContent;
      // Create rendering canvas
      HBITMAP hBmp1 = CreateDIBSection(hDC,
      &biBitmapInfo,
      DIB_PAL_COLORS,
      (void**)&pui8ImageContent,
      NULL,
      0);

      HBITMAP holdObj = (HBITMAP)SelectObject(hDC, hBmp1);
      if (NULL == holdObj)
      {
      AfxMessageBox(L"Bitmap Selection failed");
      }
      CBitmap* aBMP = CBitmap::FromHandle(hBmp);
      BITMAP* abmpDim = NULL;
      aBMP->GetBitmap(abmpDim);

      memset(pui8ImageContent, 0, m_iOverallSizeInBytes);

      LOGFONT SLogFont = {0};
      memset(&SLogFont, 0, sizeof(LOGFONT));
      SLogFont.lfHeight = 50;
      SLogFont.lfWidth = 50;
      SLogFont.lfCharSet = GB2312_CHARSET

      A Offline
      A Offline
      abrahamlincolng
      wrote on last edited by
      #2

      Have i asked the question in a wrong forum :confused:

      L 1 Reply Last reply
      0
      • A abrahamlincolng

        Have i asked the question in a wrong forum :confused:

        L Offline
        L Offline
        Lost User
        wrote on last edited by
        #3

        Nope, this is the correct forum; but your question might be a bit too advanced for most of us. I'd be looking for an alternative by now, like painting the text on a bitmap and rotate that. Did you solve your problem? If yes, how?

        Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]

        1 Reply Last reply
        0
        • A abrahamlincolng

          I am using ExtTextOut to print unicode characters in memory DC. We create font using CreateFontIndirect to print characters in different orientations. When we use GB2312_CHARSET (chinese character set) with lfEscapement/orientation set to 270 degrees the characters are printed in reverse order. If the character to be printed is 'Chinese', it is printed as 'esenihc'. The same character set works fine if lfEscapement/orientation is set to 0 deg. The issue is present only in WINCE. The same code works fine in a Win32 application. I have written a sample application.Find below the code from sample app

          CSampView::OnDraw (CDC* pDisplayDC)
          {

          HDC hDC = CreateCompatibleDC(NULL);
          HBITMAP hBmp = CreateCompatibleBitmap(hDC, width, height);
          BITMAPINFO biBitmapInfo;

          // font size may vary if screen resolution changes
          biBitmapInfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
          biBitmapInfo.bmiHeader.biWidth = 500;
          biBitmapInfo.bmiHeader.biHeight = 500;
          biBitmapInfo.bmiHeader.biPlanes = 1;
          biBitmapInfo.bmiHeader.biBitCount = 1 ;
          biBitmapInfo.bmiHeader.biCompression = BI_RGB;
          biBitmapInfo.bmiHeader.biSizeImage = 0;
          biBitmapInfo.bmiHeader.biXPelsPerMeter = 0;
          biBitmapInfo.bmiHeader.biYPelsPerMeter = 0;
          biBitmapInfo.bmiHeader.biClrUsed = 0;
          biBitmapInfo.bmiHeader.biClrImportant = 0;
          biBitmapInfo.bmiColors[0].rgbBlue = 0;
          biBitmapInfo.bmiColors[0].rgbGreen = 0;
          biBitmapInfo.bmiColors[0].rgbRed = 0;
          biBitmapInfo.bmiColors[1].rgbBlue =1;
          biBitmapInfo.bmiColors[1].rgbGreen = 1;
          biBitmapInfo.bmiColors[1].rgbRed = 1;

          CDC *pDC = CDC::FromHandle(hDC);
          /*TCHAR szString[255] = {0x0043, 0x0068, 0x0069, 0x006E, 0x0065, 0x0073, 0x0065, 0x003A, 0x0020, 0x96C5,
          0x864E, 0x641C, 0x661F, 0x575A, 0x51B3, 0x5426, 0x8BA4, 0x80E1, 0x6208, 0x63A5,
          0x62CD, 0x96C5, 0x864E, 0x5E7F, 0x544A };*/

          wchar_t szString[255] = _T("Print Test");

          PUINT8 pui8ImageContent;
          // Create rendering canvas
          HBITMAP hBmp1 = CreateDIBSection(hDC,
          &biBitmapInfo,
          DIB_PAL_COLORS,
          (void**)&pui8ImageContent,
          NULL,
          0);

          HBITMAP holdObj = (HBITMAP)SelectObject(hDC, hBmp1);
          if (NULL == holdObj)
          {
          AfxMessageBox(L"Bitmap Selection failed");
          }
          CBitmap* aBMP = CBitmap::FromHandle(hBmp);
          BITMAP* abmpDim = NULL;
          aBMP->GetBitmap(abmpDim);

          memset(pui8ImageContent, 0, m_iOverallSizeInBytes);

          LOGFONT SLogFont = {0};
          memset(&SLogFont, 0, sizeof(LOGFONT));
          SLogFont.lfHeight = 50;
          SLogFont.lfWidth = 50;
          SLogFont.lfCharSet = GB2312_CHARSET

          P Offline
          P Offline
          pasztorpisti
          wrote on last edited by
          #4

          I guess this is a bug, its not uncommon. Especially because the win32 (more maintained) sibling works well.

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups